[OPEN-ILS-DEV] Re: Localization framework status

[Dan Scott]

On 20/11/2007, Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> wrote:
> -On [20071120 02:51], Dan Scott (denials at gmail.com) wrote:
> >Note that we now have a set of POT files in build/i18n/po/ that
> >translators can start working with.
>
> Why does newpo still create the .po file(s) from the DTDs? A .po file is
> created from a .pot. :)
>
> pot2po will take the .pot file and create a .po file, merging in any
> translations already present.
>
> So normally you'd extract the messages you want from the DTDs to the .pot and
> then commit the .pot and have translators work from the committed .pot in
> order to have proper versioned collected files to work from. This keeps
> tighter grip on the entire translation effort.
>
> In this case I am a bit spoilt by Babel, since it fills in LANGUAGE in
> Language-Team. Then again, pot2po does not require any locale argument.
>
> Also, the Project-Id-Version needs to be filled in in the .pot.
>
> --
> Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
> イェルーン ラウフロック ヴァン デル ウェルヴェン
> http://www.in-nomine.org/ | http://www.rangaku.org/
> Without a soul there can be no understanding between the heart and the mind.
>

Hi Jeroen:

Thanks for the suggestions. I'm obviously still in the process of
working all of this out.

I haven't updated the project-id-version metadata as right now the
only file worth translating is opac.dtd.pot - and even that is in some
flux, as I know there will be some changes to strings as some new
search features are exposed in the catalogue in 1.2.2.

I have updated the Makefile so that "updatepo" uses pot2po to generate
the new POT files. I have also added another unit test to the
tests/testpo.py test harness to ensure that "the right thing" happens
with this approach. (It does, naturally!)

I suppose the rough process for creating a release will be something
along the lines of:
  * Release manager tags a release candidate.
  * Release manager (or someone) generates updated POT and PO files
based on the tagged release, including updating the Project-Id-Version
string to match the release version.
  * Translators update the PO files to handle any new or changed strings.
  * Release manager tags the final release.
  * Release manager (or someone) generates updated project files (DTD,
JS, etc) based on the updated PO files.
  * Release manager tars up the entire set of files, excluding the
/build/ directory, and makes the release available for download.

This process would assume that a "string freeze" would occur at
release candidate time (in the PostgreSQL project, for example, string
freeze happens at the -RC1 release) to give translators time to handle
the new and changed strings. It would also assume that the final
release would not be rolled out until an agreed-upon set of
translations were completed. This is perhaps the simplest approach,
with significant advantages for unified testing, although it tends to
have the effect of stretching out release cycles and assumes that
translators will be able to complete their work in a reasonable time
frame.

An alternative approach is to provide translations as "translation
packs" which can be downloaded and installed on top of the English
release; this would enable a given language to be made available at
any time after a release has been cut. The downside is that
integration can be more difficult -- there are more steps for the user
to take to add a language -- and testing may become more challenging
if the translations are decoupled from the core release. On the other
hand, this is the only practical approach for adding a localization
that hasn't been part of the release cycle and which wants to play
catch-up by providing a localization for the current stable release,
rather than having to wait until the next release is cut.

These are just some thoughts about possible processes. More thoughts
are appreciated, particularly if you've worked in a project with
processes that you found particularly useful (or not).

BTW: now that Mike has added locale support throughout the Perl
implementation of OpenSRF (I've seen it working, and I rejoiced!), I'm
going to have to start extending the translation framework to support
the localizations of database strings.

-- 
Dan Scott
Laurentian University