Re: [PATCH/RFC v7 1/2] Add infrastructure for translating Git with gettext

On Sat, Jun 5, 2010 at 19:27, Jonathan Nieder [off-list ref] wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

IMO trying to plan in advance what we should and shouldn't translate
is a bit premature.

I think it's better to just add glue so that everything can be
translated, then we can try decide later if some arbitrary subset
shouldn't have translations (even for human readable error messages)
and act appropriately.

Certainly there is no need to commit to decisions that will have no
observable effect.  However, setlocale()

 - takes some small amount of time (probably negligible);

 - changes the semantics of regular expression matching
  (this affects ‘git grep’, ‘git diff’'s search for a function
  header, and http-backend’s service-command regexps);

 - changes the human language used for strerror().

We could avoid these issues by turning translations off by default and
calling it experimental, which might be the right thing to do anyway.

Alternatively we can make some choice and stick to it (e.g., all git
commands use setlocale(), or just the translated ones, or whatever).
I just want to ensure it is a conscious choice.

What I'm trying to do is to make Git follow the semantics that
localized programs that use gettext traditionally do.

Everything that's translated on my desktop does pretty much what this
patch series does, i.e. calls setlocale() very early in main() so that
everything's translated and locale aware. Including strerror()
invocations and locale-aware functions like grep.

Whether it's the default or not doesn't really matter to me. Normal
users are going to get Git via their OS, and those turn on l10n
support as a matter of policy if it's available.

But since the semantics of Git will be the same unless users
explicitly request translations (by setting the LC_* variables in
their OS) I didn't see a reason not to enable it by default.