8 apr 2013 kl. 11.15 skrev Philip Martin:
Mattias Engdegård <matti...@bredband.net> writes:
The conflict prompt is no longer localised, probably because of an
oversight.
Were they localised in the past?
Yes, they were. This is what happens in 1.7:
$ LC_ALL=fr_FR.UTF-8 svn up
Conflit découvert dans '/Users/mattias/svn/prov/d1/alfa'.
Sélectionner : (p) report, (df) diff entier, (e) édite,
(mc) mes conflits, (tc) autres conflits,
(s) affiche toutes les options : s
(e) édite - résout manuellement le conflit avec un
éditeur
(df) diff complet - montre toutes les différences du fichier
fusionné
(r) résolu - utilise la version fusionnée
[etc]
Do we want the long options localised? If I run
svn update --accept=mine-conflict
the 'mine-conflict' is not localised. I don't think we want the
command
line and the prompt to be different.
In that case, perhaps the documentation for --accept should list the
possible options and what they mean -- that is standard practice for
command-line options. We could also include the (English) option
values in the "show all options" output.
After all, not translating the prompt is definitely a regression from
1.7. This is what it looks like to a non-English speaker (assuming we
fix the localisation of the base prompt and the "show all" option):
Select: (arbitrary code) gibberish, (arbitrary code) gibberish,
..., (arbitrary code) show all options:
@@ -513,7 +529,8 @@
const char *s = apr_psprintf(pool, " (%s)", opt->code);
result = apr_psprintf(pool, "%s%-6s %-16s - %s\n",
- result, s, opt->short_desc, opt-
>long_desc);
+ result, s,
+ _(opt->short_desc), _(opt-
>long_desc));
}
else
{
What about the 6 and 16, do they need to change?
The 6 is just for the option code which is not localised right now,
and even if it were, two characters would probably do even for
Finnish. The 16 could be calculated dynamically by finding the longest
of the short_desc strings after translation -- thanks for catching
that. I can modify my patch to that effect, if we agree on the design.
