[OPEN-ILS-GENERAL] TR: Question about Evergreen ILS

[Dan Scott]

On 26/07/07, Roberge, Pierre <roberge.pierre at uqam.ca> 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