Re: [PATCH/RFC v4 1/7] Add infrastructure for translating Git with gettext

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 2, 2010 at 09:12, Peter Krefting <peter@softwolves.pp.se> wrote:
> Ævar Arnfjörð Bjarmason:
>
>> +               color_fprintf_ln(s->fp, c, _("#   (use \"git rm --cached
>> <file>...\" to unstage)"));
>> +       color_fprintf_ln(s->fp, c, _("#   (use \"git add/rm <file>...\" as
>> appropriate to mark resolution)"));
>> +       color_fprintf_ln(s->fp, c, _("#"));
>
> This is a multi-line string, and should be translated as such.
>
> The trailing "#" should either be part of the translated multi-line string,
> or be added explicitely, and untranslated, at the end.
>
>> +               color_fprintf_ln(s->fp, c, _("#   (use \"git rm --cached
>> <file>...\" to unstage)"));
>> +       color_fprintf_ln(s->fp, c, _("#"));
>
> Determine how to handle the trailing "#" as above.
>
>> +               color_fprintf_ln(s->fp, c, _("#   (use \"git add/rm
>> <file>...\" to update what will be committed)"));
>> +       color_fprintf_ln(s->fp, c, _("#   (use \"git checkout --
>> <file>...\" to discard changes in working directory)"));
>
> Multi-line.
>
>> +               color_fprintf_ln(s->fp, c, _("#   (commit or discard the
>> untracked or modified content in submodules)"));
>> +       color_fprintf_ln(s->fp, c, _("#"));
>
> Trailing "#".
>
>> +       color_fprintf_ln(s->fp, c, _("#   (use \"git %s <file>...\" to
>> include in what will be committed)"), how);
>> +       color_fprintf_ln(s->fp, c, _("#"));
>
> Ditto.
>
>> +       case 1: how = _("both deleted:"); break;
>> +       case 2: how = _("added by us:"); break;
>> +       case 3: how = _("deleted by them:"); break;
>> +       case 4: how = _("added by them:"); break;
>> +       case 5: how = _("deleted by us:"); break;
>> +       case 6: how = _("both added:"); break;
>> +       case 7: how = _("both modified:"); break;
>>        }
>> -       color_fprintf(s->fp, c, "%-20s%s\n", how, one);
>> +       color_fprintf(s->fp, c, _("%-20s%s\n"), how, one);
>
> does color_fprintf() gracefully handle cutting text for multi-byte
> encodings, and text width? Otherwise I can see this bite us for all
> non-ASCII locales in general (if long translated are needed), and for CJK
> locales in particular (for variable character widths).
>
>> -               color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "%s",
>> extra.buf);
>> +               color_fprintf(s->fp, color(WT_STATUS_HEADER, s), _("%s"),
>> extra.buf);
>
> Should not be in _()
>
>> -       fprintf(s->fp, "\n");
>> +       fprintf(s->fp, _("\n"));
>
> Ditto.
>
>> +               color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s),
>> _("#"));
>> +               color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), _("#
>> Initial commit"));
>> +               color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s),
>> _("#"));
>
> Either a multi-line string, or untranslate the "#"s.

All of the points you raised are correct. This is a bad way to do
things.

It was added in Jeff in his original WIP patch as an example of
translation being possible, but I should just remove it. It's not
ready to go in for the reasons you cited.

I'll just remove the wt-status.c chunk out of the patch completely in
the next submission, and instead translate a few select strings in
some C program well.

Making things like wt-status.c translatable is going to be hard to do
properly. It uses a lot of lego (sticking strings incrementally
together), and due to the coloring of output this'll be particularly
hard to convert.

(Also, for reference, here's a general guide on how to translate C
programs well):

    http://gnu.april.org/software/automake/manual/gettext/Preparing-Strings.html