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