On 04/11/2013 03:45 AM, Mattias Engdegård wrote:
> 10 apr 2013 kl. 20.52 skrev Mattias Engdegård:
>
>> In this example, the valid shorthands for --accept ("mc" etc) also
>> double as prompt answers, but that would not have to be the case in
>> translations.
>
> On second thought, perhaps we should just drop --accept=mc and require
> the long word codes for that option instead (--accept=mine-conflicts).
> The short forms would be deprecated and not documented but still
> recognised, like the obscure "X-)" type of variants.
>
> This way, there won't be any confusion between the --accept argument and
> valid replies to the conflict prompt.
Sorry, but the values to the --accept argument and the responses to the
interactive prompter aren't natural language input. They are precisely
defined tokens that, for the purposes of this discussion, look like English
words slapped together with hyphens. They are no more "special" a part of
our command-line interface than are the subcommends and option names. As
such, localization is not required and, in fact, more likely to lead to
confusion.
Back to your previous mail:
> 1. The verbose descriptions of each conflict option. We all agree that
> these should be localised.
Yes.
> 2. The arguments to the --accept command-line flag. While it is true that
> correct programmatic use of a tool is to invoke it with LC_ALL=C or
> similar, it is not standard practice to translate command-line options in
> Unix. While this is a slight inconvenience for non-English speakers, the
> options are usually considered to symbols in a command language rather
> than words that have to be understood.
Agreed.
> 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.
Imagine that we hadn't decided to use letter-based responses, and had
instead just enumerated the options:
Select: (1) postpone, (2) show diff, (3) edit file, (4) merge,
(5) my side of conflict, (6) their side of conflict,
(0) show all options:
Clearly, there's no language-driven connection between the choice and the
meaning it carries in this situation. A new user presented with this prompt
will still have to read all the natural language descriptions, choose a
semantic response, them map that response to an otherwise meaningless
command symbol (a number), and respond by reproducing that symbol at the
prompt (and hitting <Enter>).
Users not new to Subversion who've handled such a prompt several times in
the past have already made a mental map of action to response. When they
see the prompt, their brains think L10n("postpone") and they respond "1
<enter>", exactly as a user who is familiar with a telephone menu system
would behave -- not waiting to hear the menu description, just punching in
the numbers. They've been here before; they know the way.
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.
And users that are not new to Subversion and have seen this prompt many
times will respond using their mental mappings of response symbol to action.
Their brains will think "postpone" (in their natural language) and their
fingers will respond "p <enter>". They know this menu; they've been here
before.
> 4. The abbreviated option codes for input at the conflict prompt ("e",
> "mc", etc). I argue for localisation of these to make them go with the
> rest of the conflict prompt and to be mnemonic for the user; a Finnish
> user would find it odd to answer a "kyllÀ/ei" question with "y" or "n",
> and just consider the errors waiting to happen when English abbreviations
> "match" localised strings, but the wrong ones.
Because I disagree (strongly) with your point #3, point #4 here becomes moot
in my book.
Put simply, Subversion doesn't offer a natural language input method. This
isn't a search engine. Pretty much every input to the system is a symbol --
a subcommand, an option name, an option value, a path, etc. The only
exception I can think of *might* be the datestamps we use with -r{DATE}, but
even those use an internationally commonized format, IIRC.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-04-11 14:24:55 CEST