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