On 26/07/07, Roberge, Pierre <[EMAIL PROTECTED]> wrote: > Hi everyone, > > We are following with great interest the evolution of the Evergreen project. > For our institution, the support of the French language in every part of the > system is a major issue. We are aware that the OPAC had been recently > translated. So, yesterday I send a question to Dan Scott concerning the > availability of a French version of the staff client. Dan explained to me > that there is some job to do to make the staff client able to support a > different language. > > Meanwhile, I noticed that there are some java script files that seem to > contain strings that are displayed in the client. Would'nt it be sufficient > to translate the content of these strings in the ".js" files to have a French > client up and running?
Hi Pierre: Welcome to the list! There's actually an awful lot to translate, and because most of the strings are currently hardcoded into the XHTML, XUL, and JS files, if you were just to translate the files in-place you would have to follow every commit to all of the relevant files if you wanted to keep up to date with the enhancements and bug fixes to the staff client logic. Mozilla XUL provides string bundles as a way of separating language concerns from display and business logic, and that's the ideal direction to go. So let's take a peek at a few files. For example, there is: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/xul/staff_client/server/patron/ue.xhtml -- this is a pretty straight-forward XHTML file; someone could simply move the hardcoded strings into a DTD and then all that the translators would have to worry about is just the DTD file. Side note 1: this (or the DTD) is also where things like "State" and "Zip" could get changed to "Province" and "Postal Code" in an en-CA translation. en-CA isn't only about adding "eh" to everything, eh? Side note 2: hey devs, what is the difference between this file and http://svn.open-ils.org/trac/ILS/browser/trunk/Evergreen/xul/staff_client/server/patron/ue.xhtml? Another example: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/xul/staff_client/server/patron/search_result.js -- is a pretty clean JS file, only a few alerts that would need to be moved out into a string bundle via JavaScript property files... see http://developer.mozilla.org/en/docs/Localizing_an_extension A XUL example: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/xul/staff_client/server/patron/bill_details.xul -- actually includes some localization (see line 15: <!--#include virtual="/opac/locale/en-US/lang.dtd"-->) but then more hardcoded content needs to be moved out to the DTD -- see line 272 in the handle_void() function, for example. To understand what's going on, the server is running mod_xmlent -- an apache module which can be told to automatically replace XML entities inside any file type extension you like from the DTD declared inside the file. The server needs to know which locale of the DTD to use for the entity substitution, which isn't enabled for the staff client in server mode yet. We've also talked about using those DTDs to generate string bundles that would get downloaded at connect time to provide localization support during offline mode (because, of course, you don't have an apache server to do entity substitution if you're in offline mode!). I'm also keen to implement PO files as an intermediate translation format so that changes to strings can be tracked via tools like KBabe, Pootle, translation.launchpad.ent, etc to help translators and for users to understand what point a translation in any given locale is at. But that's yet to come :) Finally, there is a fair amount of site-specific dynamic content (library names, item type names, etc) that will be stored in the database. Right now the database schema & OpenSRF protocol only understand how to deal with a single language, but Mike Rylander has a plan for teaching it to understand much, much more. So, long way of saying - yes, if you just translate the strings in place inside the existing XUL, JS, and XHTML files, it will work for a point in time, but it won't help other locales very much, and it will get out of date quickly. It would be much better if you can help us move towards entities, DTDs, property files (for JavaScript), and string bundles! -- Dan Scott Laurentian University
