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

> 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.

> 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?

>     *** 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 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.

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> 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.
>
> Thanks.
>
>>     *** 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.
>
> It would be best to get this as early as possible while not many topics
> are in 'next'; it is preferrable if we can rebase other topics in 'pu' on
> top of the result of this step.
>
>>     *** 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.
>
> Yes.  After the above two steps are done, we can pretty much independently
> advance and tweak i18n topic from other changes.
>
>>     *** 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.
>
> The last two could probably be swapped, but I think we are on the same
> page as to the overall steps and direction.

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>     *** 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.
>
> It would be best to get this as early as possible while not many topics
> are in 'next'; it is preferrable if we can rebase other topics in 'pu' on
> top of the result of this step.

> Here's a work-in-progress version of this:
> https://github.com/avar/git/compare/master...ab/i18n-c-_-only
>
> I still have to:
>
>  * Add NO_GETTEXT_POISON to more tests, some things have broken due to
>    new strings / changed tests.
>
>  * Squash the !fixup patches in appropriately.
>
> But otherwise does this seem good? I.e. having just those stub macros,
> a lot of *.c patches, including gettext.h in cache.h.

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Here's a work-in-progress version of this:
>> https://github.com/avar/git/compare/master...ab/i18n-c-_-only
>>
>> I still have to:
>>
>>  * Add NO_GETTEXT_POISON to more tests, some things have broken due to
>>    new strings / changed tests.
>>
>>  * Squash the !fixup patches in appropriately.
>>
>> But otherwise does this seem good? I.e. having just those stub macros,
>> a lot of *.c patches, including gettext.h in cache.h.
>
> I only gave a cursory look to "git diff master..ab/i18n-c-_-only" output,
> and things looked fine for a yet-to-be-completed WIP (I didn't see the
> definition of shell version of gettext and gettext_eval, for example).