On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
> I assume you mean the command line is not translated as a matter of
> policy? Technically I see no reason why it cannot be translated. If
> the reason why we don't is so that scripts can be locale-independent,
> then it would still be possible to design a UI where the '--accept=X'
> takes a set of local-independent values for X (so that scripts can be
> locale-independent) and also a set of localized values for X (for
> command-line users). I'm not saying we should do this, as that's
> something for the translators team and the rest of the development
> community to decide as a group and I'm sure it's been discussed and
> decided before, I just want to clarify what we're saying here.
That remark was about command line interfaces in general.
Generally, commands, subcommands, and option names are in English
everywhere.
I suppose in theory you could localize subcommand names, option
names, or even the name of the program binary (might not make much
sense for 'svn' but for other programs it might make sense).
But this is generally not done, at least in the realm of UNIX-like
operating systems. So this kind of thing would be something fairly
unusual and I don't think time implementing and maintaining such a
feature is time well spent.
> In general I think the interactive parts should be localized as much
> as possible, and if that means we need to do something special to the
> command-line option processing to ensure the same options can be used
> both on the command line and interactively, then I think we should do
> whatever it takes. But I will leave the decision about how much to
> localize to people such as Mattias and you who have experience of
> non-English usage (which I don't).
If people see value in doing so, sure, I won't stand in the way of
efforts to localize arguments the --accept option supports.
In theory this means that --accept cannot be used from scripts in locales
other than "C", because that is one of the few locale names specified
in the POSIX standard. In practice, locales such as en_US.UTF-8 might
also work, but there is no common standard for this.
Not sure what the implications would be on Windows.
Received on 2013-04-09 16:28:07 CEST