[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Re-localise conflict prompt

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 9 Apr 2013 16:45:33 +0100 (BST)

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.

Sure, but the specific thing we're talking about here is *only* the values of X in "--accept=X", for the purpose of maintaining equality between what you can input at the interactive prompt and what you can type at the '--accept' option on the command line.

>>  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", [...]

I was puzzled by this remark until Stefan clarified to me on IRC that he means there might be problems writing portable scripts if they use anything locale-dependent (as the names of locales are not standardized, for one thing).  But that same issue exists with stdout localization when writing a "svn info | grep URL" or "svn st | grep conflict" script, and also I suggested we could accept both localized and non-localized '--accept' values, so that doesn't worry me.

- Julian
Received on 2013-04-09 17:46:07 CEST

This is an archived mail posted to the Subversion Dev mailing list.