Junio C Hamano <gitster@xxxxxxxxx> writes:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> ...
>> + static const char *reset_type_names[] = {
>> + N_("mixed"), N_("soft"), N_("hard"), N_("merge"), N_("keep"), NULL
>> + };
>> +
>> + And then, later:
>> +
>> + die(_("%s reset is not allowed in a bare repository"),
>> + _(reset_type_names[reset_type]));
>
> I do not think this is a very good example. Unless we are doing l10n of
> option names, a Portuguese won't be typing "git reset --misto", so there
> is no point in invoking _(reset_type_names[]) to begin with, and there is
> no need to mark mixed/soft/hard/... for translation.
Ahh, I think I should take half of what I said back. The line of thought
here is that
(1) the user types "git reset --mixed"; no l10n of option names;
(2) however, various modes of operations in "reset" command have
human-readable names, not necessarily cuttable-and-pastable for
machine consumption. E.g. "git reset --mixed" is called "mixed
reset" in English and that is primarily meant to be explanation of
concept in human language, i.e. should be translated.
Under that assumption, localizing reset_type_names[] in the above may make
sense.
I said "half of", because I think the example is still problematic if you
want to translate to a language where "reset" in the fixed part of the
die() message may need to be spelled differently depending on what
adjective in reset_type_names[] it takes (or the word order between the
noun "reset" and the adjective may have to be different depending on what
the adjective is), so an example may probaby need to be more like:
static const char *error_msgs[] = {
N_("mixed reset is not allowed..."),
N_("soft reset is not allowed..."),
...
};
die("%s", _(error_msgs[reset_type]));
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html