Hi R2d2:
In message <139472afc341dd71f62927e0051d95bd6401ea8b@mirakel.one>,
r2d2@mirakel.one writes:
>I found
>https://www.roundup-tracker.org/docs/developers.html#internationalization-notes
Let me say first internationalization (i18n from now on) is not my
strong suit. I'm no C-3PO.
>But for me it is not clear if and how a new / external tracker
>template, like the todo template
>https://codeberg.org/R2D2/roundup_todo_tracker_template , fits into
>this translation system.
The deployed tracker can have a locale/ru.po, locale/de.po ... with
additional strings. IIRC this is searched first by the i18n code. If
no match is found for the key string, the installed locale files are
used.
>If I copy the todo tracker template into the roundup source tree (
>venv/share/roundup/templates ) the extraction and translation process
>works as described. But how would this work if the todo tracker is
>not integrated into roundup? Could an additional catalog be created
>and used in extension to the standard translation?
That is my understanding. See above.
>Since most of the translation strings of the todo tracker are already
>in the classic tracker.
You would only need to add the new strings using roundup-gettext to
create the pot file and then you can create .po files from that and
place them in the locale sub-directory of the installed tracker. IIUC
this is meant to allow translating stuff like status names which are
able to be changed on a per tracker basis.
AFAIK, you can publish your tracker template with a locale
subdirectory. The 'roundup-admin install' command just recursively
copies the template directory. This should copy any locale/* files as
well into the deployed tracker home.
>On a sidenote, did you know of Babel (pybabel)
>https://babel.pocoo.org/en/latest/ ? Babel is an integrated
>collection of utilities that assist in internationalizing and
>localizing Python applications, with an emphasis on web-based
>applications.
>
>Babel provides tools to build and work with gettext message catalogs
>Babel includes a command-line interface for working with message
>catalogs, similar to the various GNU gettext tools commonly available
>on Linux/Unix systems.
As a replacement for xgettext, it looked workable. A module could
probably be built to extract i18n text from TAL or Jinja templates as
well.
How to handle extraction of deferred translations (including
doc strings which supply the built in help for roundup-admin) is an
open question. It would be nice to replace xpot which is old and
unmaintained.
As far as replacing/augmenting the Python native gettext, that would
have to be done with a far better grasp of i18n/i10n than I have. It
would also make roundup internationalization dependent on an external
library which is not really a good thing.
Have a great day.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
|
