From: Jean-Noël Avila Date: Wed, 13 Apr 2022 13:11:17 GMT Subject: Re: [PATCH] Make a colon translatable Message-ID: <10867692-7c2b-1f89-d575-3d9b6e696a24@free.fr> In-Reply-To: Le 12/04/2022 à 18:32, Junio C Hamano a écrit : > Ævar Arnfjörð Bjarmason writes: > >>>> --- a/wt-status.c >>>> +++ b/wt-status.c >>>> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s, >>>> const char *how) >>>> { >>>> const char *c = color(WT_STATUS_HEADER, s); >>>> - status_printf_ln(s, c, "%s:", what); >>>> + status_printf_ln(s, c, "%s", what); >>> >>> I.e. this one is better handled by >>> >>> status_printf_ln(s, c, _("%s:"), what); >>> >>> as _(...) in C-locale is original-language centric, where we want >>> the label to be immediately followed by a colon. And that >>> allows French translation to have nbsp before the colon. >> >> In this case I think the change as suggested is better, translators get >> zero context from "%s:", whereas "Untracked files:" being status output >> is immediately obvious. > > It is unclear if you read the original (and discussion so far). > > I understand that Julien wants to turn "%s:" to have nonbreaking > whitespace before the colon. It does not matter what label we are > using (it can be "Ignored files"). I took it that the patch is > addressing "git status" output but the general thrust is in Julien's > translation, all "label-string followed by colon" should become "the > string followed by nonbreaking whitespace followed by colon". > > Moving the colon to the label string is backwards, isn't it? If the > presentation form accepted in the C-locale, i.e. "%s:", needs to be > localized in Julien's translation to "%s :", shouldn't the "%s:" > that defines the presentation be what is marked for translation? > >> His commit message also doesn't mention it, but for existing "headings" >> we already do this, e.g.: >> >> status_printf_ln(s, c, _("Changes to be committed:")); >> status_printf_ln(s, c, _("Changes not staged for commit:")); > > That's another arugment to translate _("%s:") once for the language, > I would think. Just to chime in, I would tend to approve Julien's proposal, but with a reworded commit message, which should convey that the segment to translate is not a full sentence. The main argument is that for translators to correctly work, the strings to translate must hold complete sentences, comprising the end colon. I guess that in the present case, we are quite lucky that these strings appear so often that translators know how to handle them. Why use a /* TRANSLATORS:*/ stance when simply providing the full sentence would not require any additional hint and uniformize it to the general way of presenting strings to translators. This is an indication that the string is not a complete semantic entity, although we can provide it (e.g. just like for the other ones, lines 284-305). Also making a string as generic as "%s:" translatable can lead to translation errors because this has the structure of sentence lego where we can be sure that the %s is another translated string.