======Internationalization challenges====== =====Unfriendly Forms==== /xul/server/admin/closed_dates.xhtml includes forms designed as "fill in the blank" English sentences, which won't translate well. In the following code, the '''' tags are replaced by Javascript calendar widgets and a text entry field: From at through at =====MARC editor tooltips===== There is a giant file of tooltips for the MARC editor that has been generated from the Library of Congress electronic MARC21 documentation. Where translated versions of the MARC21 standard are available, we will have to create scripts to parse and build the equivalent tooltip translations. Depending on the license of the translated work, the tooltip translations may not be able to be distributed as part of Evergreen and may have to be built by each Evergreen site instead (unless an Evergreen vendor negotiates a redistribution license with the copyright owner): * [[http://www.loc.gov/marc/translations.html|List of MARC translations]] * [[http://www.lac-bac.gc.ca/marc/040010-1000-f.html|fr-CA translation]] - electronic, yay =====Hard-coded locales in application code===== Need to check for and correct code like the following in ''Open-ILS/src/perlmods/OpenILS/WWW/SuperCat.pm'': if ($format eq 'opac') { print "Location: $root/../../en-US/skin/default/xml/rresult.xml?m=$id\n\n" if ($type eq 'metarecord'); print "Location: $root/../../en-US/skin/default/xml/rdetail.xml?r=$id\n\n" if ($type eq 'record'); return 302; } Something like the following may work: find Open-ILS/src -exec grep -H "en-US" {} \; //[ We need to teach Apache to pass the locale to mod_perl handlers (maybe it can already? %ENV is fine) and move supercat under /opac/{locale}/extras. Then a simple global replace. :) -- miker ]// =====Calendar widgets===== Currently we're hardcoding locales for calendar widgets in pages like ''Open-ILS/xul/staff_client/server/admin/closed_dates.xhtml'': ''jscalendar'' does offer versions of calendars for many popular locales. One approach would be to replace the locale with a server-side include of the locale environment variable, and create symbolic links to the full locale rather than just the two-character ''en'': cd /openils/var/web/opac/common/js/jscalendar/lang ln -sf calendar-en.js calendar-en-US.js Alternately, we could consider using the (arguably simpler) Dojo date-picker widget instead. Here's a simple example adapted from the Book of Dojo (albeit actually working in Firefox): ]> Textarea Demo =====Logic relying on parsing English text===== From ''Open-ILS/xul/server/circ/checkout.js'': 'check_date' : function(node) { JSAN.use('util.date'); try { if (node.value == 'Normal') return true; var pattern = node.value.match(/Today \+ (\d+) days/); if (pattern) { var today = new Date(); var todayPlus = new Date(); todayPlus.setTime( today.getTime() + 24*60*60*1000*pattern[1] ); node.value = util.date.formatted_date(todayPlus,"%F"); } if (! util.date.check('YYYY-MM-DD',node.value) ) { throw('Invalid Date'); } if (util.date.check_past('YYYY-MM-DD',node.value) ) { throw('Due date needs to be after today.'); } if ( util.date.formatted_date(new Date(),'%F') == node.value) { throw('Due date needs to be after today.'); } return true; } catch(E) { throw(E); } }, The problem here is that we're running a regex against an English string. A couple of approaches to solving this problem: * One regex per locale (brittle, perhaps, and requires regex knowledge that the average translator probably won't have) * Create a parallel hidden node that contains the English string and parse that instead, while the localized version is displayed (a bit tricky, but doesn't change the fundamental logic being used) * Set the value as an attribute of the node and parse that instead (possibly using a simple math notation like ''+30''). ===== Hardcoded strings in Perl modules ===== [[http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/perlmods/OpenILS/WWW/SuperCat.pm|OpenILS::WWW::SuperCat]] contains hardcoded strings and locales for the slimcat and extras (bookbags, etc). For example: sub bookbag_feed { ... if ($type eq 'opac') { print "Location: $root/../../en-US/skin/default/xml/rresult.xml?rt=list&" . join('&', map { "rl=" . $_->target_biblio_record_entry } @{ $bucket->items }) . "\n\n"; return 302; } ... $feed->title("Items in Book Bag [".$bucket->name."]"); ... $feed->link( OPAC => '/opac/en-US/skin/default/xml/rresult.xml?rt=list&' . join('&', map { 'rl=' . $_->target_biblio_record_entry } @{$bucket->items} ), 'text/html' ); } =====Org Unit shortnames===== Some code invokes the ''.shortname()'' method of an actor_org_unit object to get a short code that uniquely identifies a particular org unit and uses that for display purposes. We should audit these sections of code to find out where the shortname is being displayed directly to the user and try to replace it with the full name, where possible (keeping the shortname hidden for invoking methods if necessary). For example, in ''Open-ILS/xul/server/circ/util.js'': 'render' : function(my) { if (my.circ) { return data.hash.aou[ my.circ.circ_lib() ].shortname(); } else { if (my.acp.circulations()) { return data.hash.aou[ my.acp.circulations()[0].circ_lib() ].shortname(); } else { return ""; } }