Hi Ævar,
Ævar Arnfjörð Bjarmason wrote:
> I made three strings in git-pull.sh translatable as a proof of
> concept. One problem that I ran into is that xgettext(1) seems
> very particular when picking up translation strings. It accepts
> this:
>
> gettext "hello world"; echo
Does ‘gettext -s "hello world"’ work, too? (Just curious.)
> but not this:
[...]
>
> gettext <<"END";
> hello world
> END
>
> Maybe there's a way to make it play nice. But I just used a large
> multiline string as a workaround.
Not so nice, but it seems that gettext expects a message id as
an argument (i.e., it will only replace echo and not cat).
> I don't know what to do about
> 'die gettext' other than define a 'die_gettext' wrapper function
> and use `xgettext --keyword=die_gettext'.
Sounds sensible.
> One thing I haven't done is to try to go ahead and make massive
> changes to the Git source code to make everything translatable.
I am vaguely worried about performance. Suppose a function does
for (i = 0; i < 1000000; i++)
printf(_("Some interesting label: %s\n"), foo(i));
Will this compile to the equivalent of
const char *s = _("Some interesting label: %s\n");
for (i = 0; i < 1000000; i++)
printf(s, foo(i));
Suppose someone decides to make that change by hand (maybe the
loop is too large for the compiler to notice the potential
winnings). Then presumably gcc cannot be able to type-check the
format any more. Is there some way around this that avoids
both speed regressions and loss of type-safety?
Apologies if this was already answered in the earlier discussion.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html