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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]