On Sat, Jun 5, 2010 at 19:27, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Ævar Arnfjörð Bjarmason wrote: > >> 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. -- 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