Re: [PATCH/RFC 0/5] Add internationalization support to Git

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