Re: How you can translate things now, and a plan for the i18n series going forward

[Michael J Gruber <git@drmicha.warpmail.net>]

Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.02.2011 12:19:
> On Fri, Feb 11, 2011 at 21:22, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Fri, Feb 11, 2011 at 21:01, kev <kev@riseup.net> wrote:
>>> i understand the ab/i18n has been gettextized and translated to at
>>> least a couple of languages.
>>>
>>> ive found references in the list archives to this, but nothing in the
>>> source code. i do see translations of git-gui, however. but im looking
>>> for some clue as to how to translate git itself.
>>
>> Currently the ab/i18n branch has not been merged to master, so it's
>> not available to the general public. Ævar has been working on it but
>> we haven't heard from him recently on this topic.
> 
> Hi both. I've been on a hiatus from Git development, so I haven't
> picked up ab/i18n again, but I still plan to and to get it included in
> Git.
> 
> Meanwhile Kev, if you want to translate Git you can:
> 
>     git clone git://github.com/avar/git.git &&
>     cd git &&
>     git checkout -t origin/ab/i18n
> 
> And follow the instructions in po/README. This branch is relatively
> out of date and hasn't been rebased on the upstream master in a while,
> but most of the strings you'll be translating will still be there once
> I do that, so your work won't go to waste.
> 
> For everyone else, I plan to re-submit ab/i18n, but re-do it so that
> it isn't all one huge patch series but can be applied in smaller
> steps. Here's the outline of my current plan:
> 
>     ** TODO Re-do the i18n series so it can be applied in piecemeal steps
> 
>        I.e. these:
> 
>     *** TODO Introduce a skeleton no-op gettext, just the
> infrastructure minus the interesting stuff
> 
>         I.e. just add:
> 
>             #define N_(s) (s)
>             #define _(s) (s)
> 
>     *** TODO Add no-op C gettextize patches
> 
>         This will change "foo" to _("foo") everywhere, but will be a no-op
>         due to it being macroed out.
> 
>     *** TODO Add no-op Shell/Perl gettextize patches
> 
>         Due to the nature of these languages these can't be macroed out,
>         but it's still easy to have a no-op wrapper function.
> 
>     *** TODO Add po/README etc.
> 
>         The documentation about how to add translations etc.
> 
>     *** TODO Add translations
> 
>         Add the po/*.po files. Since we have no-op translations everywhere
>         we can translate git with xgettext + po editing, even though the
>         translations aren't being used yet.
> 
>     *** TODO Introduce the real gettext in a later patch + tests
> 
>         Once the rest is all in this will be a much smaller change.
> 
> I think doing it this way will be much easier for everyone, what do
> you think Junio?

Disclaimer: I'm not Junio :)

Sounds like a good plan, though I'm wondering whether reversing the
order of the last two would make sense review-wise (with having 1
translation for the tests), i.e. for reviewing the translations. In case
those last two should be orthogonal so that it doesn't matter.

What does matter (at least to me) is my old pet-peave suggestion for
having consistent, systematic translations: translate a/the glossary
first, then translate git messages.

_("Cheers,")
Michael