[OPEN-ILS-DEV] Localization framework status

[Dan Scott]

In the last few days, I've been working on the build/i18n/ directory
of the Evergreen tree. I just wanted to give an update on my progress
in getting a translation framework pulled together. Comments welcome!

We will be using the Translate Toolkit [1] to convert files between
DTD or JavaScript property file formats and PO format.

My current Makefile assumes that the en-US DTD and JavaScript property
files shall be the authoritative source from which the PO files shall
be generated or updated. All locales other than en-US shall store the
PO files in the Subversion repository (in the appropriate
/build/i18n/po/ll-LL/) directory, and these locales shall generate
their DTD and JavaScript property files generated from a set of PO
files at build time. The release manager will be responsible for
adding the generated files to the release tarballs.

To generate a brand new set of PO files for a given locale, issue the
following commands from the build/i18n/ directory (where ll-LL
represents the language / region combination of IANA language tag
subtag [2] and ISO 3166-1-alpha-code [3]):

make LOCALE=ll-LL newpo

This will create a new set of PO files in the build/i18n/po/ll-LL/ directory.

If you have begun localizing the DTD or JavaScript property files and
the files are in the build tree in a directory relative to the en-US
files, such as was the case with en-CA and fr-CA for opac.dtd, you can
then update the new set of PO files you just generated with the
following command:

make LOCALE=ll-LL updatepo

This will update the set of PO files in the build/i18n/po/ll-LL/ directory.

To generate a new set of DTD and JavaScript property files containing
whatever localizations have been made for a certain set of strings:

make LOCALE=ll-LL updatemoz

This will generate a set of DTD and JavaScript property files for the
requested locale in the build/i18n/locale/ll-LL/ directory that
contain localized strings. If a localization was not provided for a
given string, then the en-US string will automatically be provided.

A basic set of unit tests for the preceding scenarios has been
included in build/i18n/tests/testpo.py.

Some thoughts:
  * The fr-CA and en-CA opac.dtd files that are currently checked into
trunk should be deleted if we have general agreement that this is the
direction we want to take.
  * This does not yet represent a complete set of localizable strings.
Need to extend the framework to support localization of default
database field values, fm_IDL.xml reporter labels, ils_events.xml, and
eventually the Evergreen manual and contextual help.
  * The Makefile will need to be extended to automatically generate
all of the supported / up-to-date locales to avoid too much manual
work for the release manager.
  * The Makefile will need to be taught to place the generated files
into the appropriate locations in the build tree to avoid too much
manual work for the release manager.
  * Maybe we'll need to convert to something more flexible than a
Makefile to ease the previous two items.
  * Still need to set up Pootle [1], use the Launchpad Translation
Manager [4], or set up some other translation management tool to take
full advantage of the benefits offered by the PO format.

[1] http://translate.sourceforge.net
[2] http://www.iana.org/assignments/language-subtag-registry - note
that we might end up supporting three-character language codes after
all - mea culpa Mike
[3] http://www.iso.org/iso/english_country_names_and_code_elements
[4] https://translations.launchpad.net/

-- 
Dan Scott
Laurentian University