On 09.04.2013 16:27, Stefan Sperling wrote: > 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.
I frankly cannot recall a single tool that localizes its command line, either commands, options or option values. That way lies insanity; you might as well localize C. On the other hand, I wouldn't mind localizing the interactive prompts, except for the actual command codes. So the example French translation of the conflict prompt makes perfect sense to me. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
