Re: [PATCH 1/5] Internationalization of git-gui

From: Christian Stimming <stimming@tuhh.de>
Date: Jul 22, 2007, 13:35 UTC
Message-ID: <200707221535.46422.stimming@tuhh.de>
In-Reply-To: <7vabtpv43d.fsf@assigned-by-dhcp.cox.net>

Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:

Show 10 quoted lines

> > Agreed. I propose to throw away the "add glossary" patch and I'll
> > resubmit, this time in a separate po/glossary/ directory, where each
> > language will get a po file for the glossary.
>
> Actually, I would even suggest that we should NOT have a
> separate glossary file at all, if gettext suite allows what I
> outline below.
>
> How about having it as a part of header comment in each of the
> xx.po file?

I don't think this would work well. In particular, you don't get all the nice gettext *merging* features that you only get with a full-blown po file.

Show 5 quoted lines

> The division of labor I think would make sense for message l10n
> process goes like this:
>
>  - The software developer (primarily Shawn): responsible for
>    marking messages subject to i18n;

Yes, except those developers who don't happen to be translators as well tend to forget the markups. I don't blame anyone for doing so - just keep in mind that translators have to give feedback about missing markups, and they hopefully will do so.

Show 5 quoted lines

>  - The i18n coordinator (could be Shawn but anybody else can
>    volunteer; as things stand, I think Christian and Johannes
>    are doing this): responsible for running "make
>    po/git-gui.pot; make update-po" from time to time in order to
>    keep po/*.po in sync with the vocabulary.

Actually, please DO NOT RUN update-po except right before a new tarball is being packaged and distributed! It sucks royally if I have updated my de.po translation, only to discover someone has run update-po on the server and I have to figure out how to get out of the de.po conflicts. There will be conflicts after each and every update-po because the line numbers in the po file will have changed inevitably -- but the actualy content in terms of messages might be completely unchanged.

For that reason, please use the update-po rule AS SELDOM AS POSSIBLE. Thanks a lot.

>    initially, populate "glossary" part in po/git-gui.pot;
>
>    as needed, add entries "glossary" part in po/git-gui.pot, and
>    (if possible) add corresponding placeholders to po/*.po;

Again, this doesn't work well, and depending on the po file editor that is used by a translator they might not see this comment block anyway. I would instead propose a subdirectory po/glossary; a CSV file that contains the terms itself; a csv-to-po converter script that will turn the terms into a git-gui-glossary.pot; and a po file for each language.

Show 12 quoted lines

>  - Translators (one for each language): responsible for updating
>    po/xx.po file;
>
>    initially, start by copying po/git-gui.pot to create
>    po/xx.po;
>
>    maintainance of "glossary" part of po/xx.po could also be
>    made this person's responsibility instead of i18n
>    coordinator's.
>
> This way, the translators do not have to be so familiar with the
> gettext toolchain nor even have to have gettext installed.

Translators who are unfamiliar with gettext are a mixed blessing. Anyone is able to contribute a bunch of initial string translations, especially if there hasn't been a translation before. But if someone or a team wants to achieve a really *high-quality*, 100%, consistent, and understandable translation, the translators must be able to test the translation a lot, which implies they must be able to generate the .msg files, which requires the gettext toolchain anyway. For that reason I wouldn't spent too much effort to enable translation work without gettext tools; instead, I'd rather encourage to optimize the setup for those translators that have the full toolchain available.

Christian