[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: Wed, 10 Apr 2013 20:52:49 +0200

9 apr 2013 kl. 16.08 skrev Julian Foad:

> 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).

Let us enumerate the strings under consideration:

1. The verbose descriptions of each conflict option. We all agree that
these should be localised.

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.

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.

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.

Since the--accept command arguments would then no longer appear in the
conflict menu, I suggest that they be part of the long help output as
well as the --accept argument description. This is what it might look
like in English:

Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
         (mc) my side of conflict, (tc) their side of conflict,
         (s) show all options: s

  (e) change merged file in an editor [edit, e]
  (df) show all changes made to merged file
  (r) accept merged version of file

  (dc) show all conflicts (ignoring merged version)
  (mc) accept my version for all conflicts (same) [mine-conflict, mc]
  (tc) accept their version for all conflicts (same) [theirs-conflict,
tc]
[...]
Words within square brackets are the corresponding --accept arguments.

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.
Received on 2013-04-10 20:53:27 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.