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

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

[Ævar Arnfjörð Bjarmason]

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?

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

[Michael J Gruber]

Æ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

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

[Junio C Hamano]

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

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

[Ævar Arnfjörð Bjarmason]

On Sat, Feb 12, 2011 at 21:12, Junio C Hamano <gitster@pobox.com> wrote:
> Æ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.

Right, good to hear we're on the same page.

I'll be doing a Perl release on the 20th, and I'm traveling around,
but I hope to get around to this sooner rather than later.

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

[Ævar Arnfjörð Bjarmason]

On Sat, Feb 12, 2011 at 21:12, Junio C Hamano <gitster@pobox.com> wrote:
> Æ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.

And having NO_GETTEXT_POISON be part of the actual patches, of course
I'd also have to add something to the test suite to always set that
for now.

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

[Junio C Hamano]

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

Thanks.

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

[Ævar Arnfjörð Bjarmason]

On Thu, Feb 17, 2011 at 01:46, Junio C Hamano <gitster@pobox.com> wrote:
> Æ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).

I'm going to submit the C ones first, and do the shell and Perl ones
later if that's OK with you.