[Vimperator] Translation infrastructure
Yves Rutschle
vim at rutschle.net
Sat Oct 20 04:43:34 PDT 2007
On Fri, Oct 19, 2007 at 01:51:06PM +0200, Martin Stubenschrott wrote:
> There is a mechanism for translations in mozilla:
>
> http://developer.mozilla.org/en/docs/XUL_Tutorial:Property_Files
>
> Still, my main point stays, that vimperator is still very much a moving
> target, and even core commands like :echo change semantics and therefore
> the documentation, having outdated (translated) documentation can really
> cause problems there.
>
> Hmm, the only sane way would be to be able to specify in a sane way that
> a string needs updating, otherwise, how should translators even know,
> that they need to update certain strings?
That's exactly what gettext and po4a do: they create a
catalog of messages (a so-called PO file), the translators
translate them, and the software uses the catalogs. When the
target moves, gettext updates the catalog, keeping track of
what's changed, and what's added. When a translation hasn't
been updated, it uses the new English string (so in case of
incomplete translation, you effectively end up with the
messages in two languages...)
These property files look like the way to go indeed. I am
not at all sure how you'd go about coding the Javascript
side (I know nothing about XUL and not much about
Javascript...) nor how you'd select the proper property
file... but the idea would be to get all the strings out of
the code, into a property file, run po4a on it to generate
the PO message catalogs, then generate one property file per
language. Then somehow Vimperator decides what language file
to use.
Í'll be happy to do the po4a part for you and help out with
the i18n part (i18n: internationalisation => making the code
amenable to being translated, i.e. in our case moving the
strings out of the source; then comes l10n: localisation,
the act of actually translating the program).
Y.
More information about the Vimperator
mailing list