Re: [PATCH 03/65] i18n: archive: mark parseopt strings for translation

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 30, 2012, 06:24 UTC
Message-ID: <20120530062424.GA19114@burratino>
In-Reply-To: <CACsJy8BvZSbsXyh3ct-M3rcWQf9Fw4VDX2VYVy+0Hv+53AQWnw@mail.gmail.com>

Nguyen Thai Ngoc Duy wrote:

>                             Or generate a poisoned .mo file, then make
> git use that.

Yes, I would like that very much. I had vague ideas of using some valid language code that doesn't correspond to a human language, but an alternate GIT_TEXTDOMAINDIR might be simpler and work better.

> Another thing is GETTEXT_POISON poisons too much. printf(_("this is
> %s\n"), path); is turned to "# GETTEXT POISON #". There's no way for
> test scripts to verify the correct "path" output.

Somes like a good change. ;)

"this is %s\n" could be translated to "poison(%s)" or even "THIS IS %s\n" to make it easy to recognize which string was poisoned.

When i18n plumbing was starting I thought this would be important and made a mental note to implement a rot13 function that preserves printf directives. In the end I have wanted it much less often than I thought I would. In tests that check the effect of commands on a repository, only checking the output of plumbing commands is just a good idea anyway. (But I can understand that preserving printf directives would be useful for people wanting to test the UI.)

UI tests are tricky. I can't imagine how a good test for translated request-pull that doesn't pick a particular language could work, for example.

Well, hopefully the above is amusing.  Sorry to ramble.

Thanks much again for this series --- the translated help makes it much easier to imagine git to be a native speaker in a locale where English is not the main language.

Jonathan