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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 30, 2010, 01:46 UTC
Message-ID: <20100530014607.GA27387@progeny.tock>
In-Reply-To: <1275173125-21010-1-git-send-email-avarab@gmail.com>

Hi Ævar,

Ævar Arnfjörð Bjarmason wrote:

Show 6 quoted lines

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

[...]

Show 7 quoted lines

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