[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: Mattias Engdegård <mattiase_at_bredband.net>
Date: Thu, 11 Apr 2013 20:47:38 +0200

11 apr 2013 kl. 14.24 skrev C. Michael Pilato:

> On 04/11/2013 03:45 AM, Mattias Engdegård wrote:
[...]
>> 3. The options that appear in the conflict prompt. These, I strongly
>> believe, should all be translated, since it is essentially a menu of
>> choices for the user. Note that this means that they will no longer
>> be
>> the same as those used for --accept, but this is also an advantage:
>> it
>> permits us to use proper English in the prompt, rather than
>> keywords such
>> as "mine-conflict", just like most translations do in 1.7.
>
> Here we disagree. The conflict prompt choices are also symbols of a
> command
> language, and non-English users should treat them as such.

I take it that you disagree with the suggestion to translate the
user's replies, not the actual labels in the conflict prompt (which is
what I actually meant by the paragraph you quoted). Sorry expressing
myself badly.

> This is no different than our use of letters and strings thereof for
> our
> responses. A new user of Subversion presented with this prompt will
> *still*
> have to read all the descriptions, *still* have to note the symbolic
> response for the choice they wish to make, and *still* have to
> reproduce
> that response at the prompt. That the letters used in the response
> symbols
> happen to somewhat resemble the letters used in the description is
> largely
> disinteresting. They cognitive effort required to understand the
> choices
> and make one has already been paid by the time that detail is even
> noticed,
> if it ever is.

Do you really claim that any set of single- and two-letter codes is as
good as another? I don't think so -- I believe "p" to be better
answer for "postpone" than "4" or "mc" in English, one that will both
reach the state of memorisation much quicker and reduce the risk of
errors.

And if you would agree to that, why should we deny others the same
benefits?
Received on 2013-04-11 21:38:26 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.