{"thread":{"id":"57708","subject":"[PATCH] Make a colon translatable","startedAt":"2022-04-11T07:02:27Z","lastAt":"2022-04-13T16:48:35Z","messageCount":8,"participants":["Julien Palard","Junio C Hamano","Ævar Arnfjörð Bjarmason","Jean-Noël Avila"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"453389","messageId":"-9xEw4skKJRhRp5v7WmxeS2n5xv-xmM0HWqmoiameagKhpiDOP9y3Yxj7WFy6M-jztxqug8DKopXIr_op09VlGPkUC7iG5V6xXjKh_SxHEg=@palard.fr","threadId":"57708","inReplyTo":null,"subject":"[PATCH] Make a colon translatable","fromName":"Julien Palard","fromEmail":"julien@palard.fr","sentAt":"2022-04-11T07:02:14Z","receivedAt":"2022-04-11T07:02:27Z","isPatch":true,"sender":{"key":"julien@palard.fr","avatar":null},"body":"In french we use a no-break space before colon, so with formatting\nlike:\n\n    printf(\"... %s: ...\", _(\"some string\"))\n\nWe can't cleanly add our no-break space, so I think:\n\n    printf(\"... %s ...\", _(\"some string:\"))\n\nis better for translators.\n\nSigned-off-by: Julien Palard <julien@palard.fr>\n---\n wt-status.c | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex d33f9272b7..ef0c276c3d 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n \t\t\t\t\t     const char *how)\n {\n \tconst char *c = color(WT_STATUS_HEADER, s);\n-\tstatus_printf_ln(s, c, \"%s:\", what);\n+\tstatus_printf_ln(s, c, \"%s\", what);\n \tif (!s->hints)\n \t\treturn;\n \tstatus_printf_ln(s, c, _(\"  (use \\\"git %s <file>...\\\" to include in what will be committed)\"), how);\n@@ -1863,9 +1863,9 @@ static void wt_longstatus_print(struct wt_status *s)\n \t\twt_longstatus_print_submodule_summary(s, 1);  /* unstaged */\n \t}\n \tif (s->show_untracked_files) {\n-\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files\"), \"add\");\n+\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files:\"), \"add\");\n \t\tif (s->show_ignored_mode)\n-\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files\"), \"add -f\");\n+\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files:\"), \"add -f\");\n \t\tif (advice_enabled(ADVICE_STATUS_U_OPTION) && 2000 < s->untracked_in_ms) {\n \t\t\tstatus_printf_ln(s, GIT_COLOR_NORMAL, \"%s\", \"\");\n \t\t\tstatus_printf_ln(s, GIT_COLOR_NORMAL,\n--\n2.35.1\n\n-- \nJulien Palard\nhttps://mdk.fr\n"},{"id":"453428","messageId":"xmqq5ynfh101.fsf@gitster.g","threadId":"57708","inReplyTo":"-9xEw4skKJRhRp5v7WmxeS2n5xv-xmM0HWqmoiameagKhpiDOP9y3Yxj7WFy6M-jztxqug8DKopXIr_op09VlGPkUC7iG5V6xXjKh_SxHEg=@palard.fr","subject":"Re: [PATCH] Make a colon translatable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-11T19:29:50Z","receivedAt":"2022-04-11T19:29:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julien Palard <julien@palard.fr> writes:\n\n> In french we use a no-break space before colon, so with formatting\n> like:\n>\n>     printf(\"... %s: ...\", _(\"some string\"))\n>\n> We can't cleanly add our no-break space, so I think:\n>\n>     printf(\"... %s ...\", _(\"some string:\"))\n\nSorry, but I do not quite buy this.  The above is a representative\nexample of what we call \"sentence lego\", which is what we absolutely\nwant to avoid, isn't it?\n\nWe'd rather want to see\n\n\tprintf_like_function(_(\"Use 'git %s' ...\", \"string\"));\n\nwhen \"string\" is something that should not be translated to begin\nwith (e.g. \"add\" to form \"git add\"), and different languages can use\ndifferent conventions for quoting the command name (a translation\nmay want to use something other than single-quotes, for example).\n\nAnd in a less optimal case,\n\n\tprintf_like_function(_(\"%s: ...\", _(\"string\")));\n\nwould be needed, when \"string\" is something that is to be translated\n(e.g. a phrase used as a label, like \"Untracked files\" in the code\nthis patch touches).  I think the case you have is the latter one.\n\n> diff --git a/wt-status.c b/wt-status.c\n> index d33f9272b7..ef0c276c3d 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n>  \t\t\t\t\t     const char *how)\n>  {\n>  \tconst char *c = color(WT_STATUS_HEADER, s);\n> -\tstatus_printf_ln(s, c, \"%s:\", what);\n> +\tstatus_printf_ln(s, c, \"%s\", what);\n\nI.e. this one is better handled by\n\n\tstatus_printf_ln(s, c, _(\"%s:\"), what);\n\nas _(...) in C-locale is original-language centric, where we want\nthe label to be <phrase> immediately followed by a colon.  And that\nallows French translation to have nbsp before the colon.\n\n>  \tif (s->show_untracked_files) {\n> -\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files\"), \"add\");\n> +\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files:\"), \"add\");\n\nThen this <phrase>, to be used in the label above, can be without colon.\n\n>  \t\tif (s->show_ignored_mode)\n> -\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files\"), \"add -f\");\n> +\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files:\"), \"add -f\");\n\nDitto.\n\nThanks.\n"},{"id":"453438","messageId":"220412.86tuayhga7.gmgdl@evledraar.gmail.com","threadId":"57708","inReplyTo":"xmqq5ynfh101.fsf@gitster.g","subject":"Re: [PATCH] Make a colon translatable","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-12T08:03:48Z","receivedAt":"2022-04-12T10:01:17Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 11 2022, Junio C Hamano wrote:\n\n> Julien Palard <julien@palard.fr> writes:\n>\n>> In french we use a no-break space before colon, so with formatting\n>> like:\n>>\n>>     printf(\"... %s: ...\", _(\"some string\"))\n>>\n>> We can't cleanly add our no-break space, so I think:\n>>\n>>     printf(\"... %s ...\", _(\"some string:\"))\n>\n> Sorry, but I do not quite buy this.  The above is a representative\n> example of what we call \"sentence lego\", which is what we absolutely\n> want to avoid, isn't it?\n>\n> We'd rather want to see\n>\n> \tprintf_like_function(_(\"Use 'git %s' ...\", \"string\"));\n>\n> when \"string\" is something that should not be translated to begin\n> with (e.g. \"add\" to form \"git add\"), and different languages can use\n> different conventions for quoting the command name (a translation\n> may want to use something other than single-quotes, for example).\n>\n> And in a less optimal case,\n>\n> \tprintf_like_function(_(\"%s: ...\", _(\"string\")));\n>\n> would be needed, when \"string\" is something that is to be translated\n> (e.g. a phrase used as a label, like \"Untracked files\" in the code\n> this patch touches).  I think the case you have is the latter one.\n\nYou're right, but wt-status.c is sentence lego galore, and that's been a\nTODO since the i18n effort was started.\n\nIt's particularly hard to peel it apart, and doing so would require\ne.g. having translators translate a string with embedded color formats,\nor even git-for-each-ref embedded %(if...) formats.\n\nBut in lieu of that I don't see a reson for not taking this much more\nnarrow change, since it solves a practical issue for a major language...\n\n>> diff --git a/wt-status.c b/wt-status.c\n>> index d33f9272b7..ef0c276c3d 100644\n>> --- a/wt-status.c\n>> +++ b/wt-status.c\n>> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n>>  \t\t\t\t\t     const char *how)\n>>  {\n>>  \tconst char *c = color(WT_STATUS_HEADER, s);\n>> -\tstatus_printf_ln(s, c, \"%s:\", what);\n>> +\tstatus_printf_ln(s, c, \"%s\", what);\n>\n> I.e. this one is better handled by\n>\n> \tstatus_printf_ln(s, c, _(\"%s:\"), what);\n>\n> as _(...) in C-locale is original-language centric, where we want\n> the label to be <phrase> immediately followed by a colon.  And that\n> allows French translation to have nbsp before the colon.\n\nIn this case I think the change as suggested is better, translators get\nzero context from \"%s:\", whereas \"Untracked files:\" being status output\nis immediately obvious.\n\n>>  \tif (s->show_untracked_files) {\n>> -\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files\"), \"add\");\n>> +\t\twt_longstatus_print_other(s, &s->untracked, _(\"Untracked files:\"), \"add\");\n>\n> Then this <phrase>, to be used in the label above, can be without colon.\n>\n>>  \t\tif (s->show_ignored_mode)\n>> -\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files\"), \"add -f\");\n>> +\t\t\twt_longstatus_print_other(s, &s->ignored, _(\"Ignored files:\"), \"add -f\");\n\nIt's a good rule of thumb to give translators the \"whole thing\", in this\ncase that's a heading, so despite other issues with lego'd \"status\"\noutput this particular string is following best-practices after this\nchange by Julien.\n\nHis commit message also doesn't mention it, but for existing \"headings\"\nwe already do this, e.g.:\n\n    status_printf_ln(s, c, _(\"Changes to be committed:\"));\n    status_printf_ln(s, c, _(\"Changes not staged for commit:\"));\n\netc., grep for status_printf_ln.*\" in that file, so this is making\nthings consistent with that other code.\n"},{"id":"453443","messageId":"CmgFntqFQcIxsSKePSKmmWvAMwsl-9shDqzWTT9GqI3S6PXNdhTTX6LypjY0l-R8B52pkh_MpYtq-NbbDjXT6EuZ9_S-QV4cUqxKhjZUpw8=@palard.fr","threadId":"57708","inReplyTo":"xmqq5ynfh101.fsf@gitster.g","subject":"Re: [PATCH] Make a colon translatable","fromName":"Julien Palard","fromEmail":"julien@palard.fr","sentAt":"2022-04-12T07:30:10Z","receivedAt":"2022-04-12T10:01:25Z","isPatch":true,"sender":{"key":"julien@palard.fr","avatar":null},"body":"Hi, thanks for you feedback!\n\n> Sorry, but I do not quite buy this. The above is a representative\n> example of what we call \"sentence lego\", which is what we absolutely\n> want to avoid, isn't it?\n\nI never heard of \"sentence lego\" but I can easily imagine it's building sentences by mixing multiple levels of gettext and printf-like formatting, typically freezing the order of sentence components, rendering them untranslatable in some languages, like printf(_(\"if %s then %s\"), _(if_part), _(then_part))? I I'm wrong tell me because I may have misundertood your whole point.\n\n> We'd rather want to see\n>\n> printf_like_function((\"Use 'git %s' ...\", \"string\"));\n>\n> when \"string\" is something that should not be translated\n\nMake sense.\n\n> I.e. this one is better handled by\n>\n> status_printf_ln(s, c, _(\"%s:\"), what);\n\nI understand your comment while seeing my badly choosen example with `_(\"some string:\")`, but in the patch isn't your proposition more sentence-lego-ish than mine? If I understand correctly you're proposing to replace:\n\n    printf(\"%s\", _(\"Untracked files:\"))\n\nwith:\n\n    printf(_(\"%s:\"), _(\"Untracked files\"))\n\nThis hides information to the translator (the presence of a following colon while translating 'Untracked files'). It would be OK if we were 100% sure no translations can be impacted by this. I only speak french and english, so I don't know. Maybe I should rename `what` to `heading`? I may clarify a bit, `what` make me feel it can be reused, but it's only used once alone on its line.\n\nBests,\n-- \nJulien Palard\nhttps://mdk.fr\n\n"},{"id":"453448","messageId":"xmqq8rsaclom.fsf@gitster.g","threadId":"57708","inReplyTo":"CmgFntqFQcIxsSKePSKmmWvAMwsl-9shDqzWTT9GqI3S6PXNdhTTX6LypjY0l-R8B52pkh_MpYtq-NbbDjXT6EuZ9_S-QV4cUqxKhjZUpw8=@palard.fr","subject":"Re: [PATCH] Make a colon translatable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-12T16:26:33Z","receivedAt":"2022-04-12T16:26:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julien Palard <julien@palard.fr> writes:\n\n> I understand your comment while seeing my badly choosen example\n> with `_(\"some string:\")`, but in the patch isn't your proposition\n> more sentence-lego-ish than mine? If I understand correctly you're\n> proposing to replace:\n>\n>     printf(\"%s\", _(\"Untracked files:\"))\n>\n> with:\n>\n>     printf(_(\"%s:\"), _(\"Untracked files\"))\n\nHmph, I am talking about\n\ndiff --git i/wt-status.c w/wt-status.c\nindex d33f9272b7..f475194ff8 100644\n--- i/wt-status.c\n+++ w/wt-status.c\n@@ -249,5 +249,5 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n {\n \tconst char *c = color(WT_STATUS_HEADER, s);\n-\tstatus_printf_ln(s, c, \"%s:\", what);\n+\tstatus_printf_ln(s, c, _(\"%s:\"), what);\n \tif (!s->hints)\n \t\treturn;\n\nwhere the callers already supply _(\"Untracked files\") and _(\"Ignored files\")\nwithout trailing colon in \"what\" when calling wt_longstatus_print_other(),\nwhich is a direct caller that passes \"what\" to this function.\n\nSo, no, I am replacing\n\n\tprintf(\"%s:\", _(\"Untracked files\"))\n\nwith\n\n\tprintf(_(\"%s:\"), _(\"Untracked files\"))\n\nand no other changes are required.  When translating \"%s:\", French\ntranslation can insert nbsp before the colon to make it \"%s :\",\nright to left languages may want to put their equivalent to colon\nthat comes after a heading on the left side of the \"%s\", etc.\n\n> This hides information to the translator (the presence of a\n> following colon while translating 'Untracked files').\n\nWith \"Untracked files\" and \"Ignored files\", we indicate certain\nconcepts and interpolate it in _(\"%s:\"), i.e. a version localized to\nadjust to the presentation convention of \"label followed by a\nseparating colon\".  Unless your language requires to translate\n\"Untracked files\" differently when it is used as a \"label\" to be\nfollowed by a separating colon and when it appears elsewhere in a\nsentence, I am not sure how it helps to mark \"Untracked files\" as\nappearing as a header label.\n\nBesides, in the existing code, the form that is equivalent to\n\n\tprintf(\"%s:\", _(\"Untracked files\"))\n\nis being used, and where that \"Untracked files\" appear is two level\nfunction calls away from the actual \"%s:\" (i.e. \"label and\nseparator\").  Aren't translators translating this string without\nextra context?\n\n> It would be\n> OK if we were 100% sure no translations can be impacted by this. I\n> only speak french and english, so I don't know. Maybe I should\n> rename `what` to `heading`? I may clarify a bit, `what` make me\n> feel it can be reused, but it's only used once alone on its line.\n\nThe way the function wt_longstatus_print_other() uses \"what\" and\n\"how\" looks quite clear.  What kind of paths are being reported (are\nthey ignored files?  untracked files?  something else?) and how the\nuser can rectify the situation if they want these paths included in\nthe tracked set of paths.  I am afraid renaming to \"heading\" makes\nit even less clear than leaving it to \"what\".  A word that indicates\nthat it refers to \"category of paths\" more clearly may make a good\nreplacement, but perhaps I am not understanding where exactly your\n\"this hides the information\" comes from and makes you worry about\nit.  Besides, would translators work off of .po and .pot files, not\nthe C-source?  Do they even have ready access to the variable names\nto help them infer how the strings are used to begin with?\n\nIf translators truly benefit from knowing that the string \"Untracked\nfiles\" is used as a heading, we could use /* TRANSLATORS: insn */\ncomment to help them.  Since I seem not to get where your concern\ncomes from, I cannot tell if it would help.\n\nMore info needed, I guess?\n"},{"id":"453449","messageId":"xmqq35iicle2.fsf@gitster.g","threadId":"57708","inReplyTo":"220412.86tuayhga7.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] Make a colon translatable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-12T16:32:53Z","receivedAt":"2022-04-12T16:33:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>>> --- a/wt-status.c\n>>> +++ b/wt-status.c\n>>> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n>>>  \t\t\t\t\t     const char *how)\n>>>  {\n>>>  \tconst char *c = color(WT_STATUS_HEADER, s);\n>>> -\tstatus_printf_ln(s, c, \"%s:\", what);\n>>> +\tstatus_printf_ln(s, c, \"%s\", what);\n>>\n>> I.e. this one is better handled by\n>>\n>> \tstatus_printf_ln(s, c, _(\"%s:\"), what);\n>>\n>> as _(...) in C-locale is original-language centric, where we want\n>> the label to be <phrase> immediately followed by a colon.  And that\n>> allows French translation to have nbsp before the colon.\n>\n> In this case I think the change as suggested is better, translators get\n> zero context from \"%s:\", whereas \"Untracked files:\" being status output\n> is immediately obvious.\n\nIt is unclear if you read the original (and discussion so far).\n\nI understand that Julien wants to turn \"%s:\" to have nonbreaking\nwhitespace before the colon.  It does not matter what label we are\nusing (it can be \"Ignored files\").  I took it that the patch is\naddressing \"git status\" output but the general thrust is in Julien's\ntranslation, all \"label-string followed by colon\" should become \"the\nstring followed by nonbreaking whitespace followed by colon\".\n\nMoving the colon to the label string is backwards, isn't it?  If the\npresentation form accepted in the C-locale, i.e. \"%s:\", needs to be\nlocalized in Julien's translation to \"%s :\", shouldn't the \"%s:\"\nthat defines the presentation be what is marked for translation?\n\n> His commit message also doesn't mention it, but for existing \"headings\"\n> we already do this, e.g.:\n>\n>     status_printf_ln(s, c, _(\"Changes to be committed:\"));\n>     status_printf_ln(s, c, _(\"Changes not staged for commit:\"));\n\nThat's another arugment to translate _(\"%s:\") once for the language,\nI would think.\n"},{"id":"453477","messageId":"10867692-7c2b-1f89-d575-3d9b6e696a24@free.fr","threadId":"57708","inReplyTo":"xmqq35iicle2.fsf@gitster.g","subject":"Re: [PATCH] Make a colon translatable","fromName":"Jean-Noël Avila","fromEmail":"jn.avila@free.fr","sentAt":"2022-04-13T13:11:17Z","receivedAt":"2022-04-13T13:11:28Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le 12/04/2022 à 18:32, Junio C Hamano a écrit :\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n>>>> --- a/wt-status.c\n>>>> +++ b/wt-status.c\n>>>> @@ -248,7 +248,7 @@ static void wt_longstatus_print_other_header(struct wt_status *s,\n>>>>   \t\t\t\t\t     const char *how)\n>>>>   {\n>>>>   \tconst char *c = color(WT_STATUS_HEADER, s);\n>>>> -\tstatus_printf_ln(s, c, \"%s:\", what);\n>>>> +\tstatus_printf_ln(s, c, \"%s\", what);\n>>>\n>>> I.e. this one is better handled by\n>>>\n>>> \tstatus_printf_ln(s, c, _(\"%s:\"), what);\n>>>\n>>> as _(...) in C-locale is original-language centric, where we want\n>>> the label to be <phrase> immediately followed by a colon.  And that\n>>> allows French translation to have nbsp before the colon.\n>>\n>> In this case I think the change as suggested is better, translators get\n>> zero context from \"%s:\", whereas \"Untracked files:\" being status output\n>> is immediately obvious.\n> \n> It is unclear if you read the original (and discussion so far).\n> \n> I understand that Julien wants to turn \"%s:\" to have nonbreaking\n> whitespace before the colon.  It does not matter what label we are\n> using (it can be \"Ignored files\").  I took it that the patch is\n> addressing \"git status\" output but the general thrust is in Julien's\n> translation, all \"label-string followed by colon\" should become \"the\n> string followed by nonbreaking whitespace followed by colon\".\n> \n> Moving the colon to the label string is backwards, isn't it?  If the\n> presentation form accepted in the C-locale, i.e. \"%s:\", needs to be\n> localized in Julien's translation to \"%s :\", shouldn't the \"%s:\"\n> that defines the presentation be what is marked for translation?\n> \n>> His commit message also doesn't mention it, but for existing \"headings\"\n>> we already do this, e.g.:\n>>\n>>      status_printf_ln(s, c, _(\"Changes to be committed:\"));\n>>      status_printf_ln(s, c, _(\"Changes not staged for commit:\"));\n> \n> That's another arugment to translate _(\"%s:\") once for the language,\n> I would think.\n\nJust to chime in, I would tend to approve Julien's proposal, but with a \nreworded commit message, which should convey that the segment to \ntranslate is not a full sentence.\n\n\nThe main argument is that for translators to correctly work, the strings \nto translate must hold complete sentences, comprising the end colon. I \nguess that in the present case, we are quite lucky that these strings \nappear so often that translators know how to handle them.\n\nWhy use a /* TRANSLATORS:*/ stance when simply providing the full \nsentence would not require any additional hint and uniformize it to the \ngeneral way of presenting strings to translators. This is an indication \nthat the string is not a complete semantic entity, although we can \nprovide it (e.g. just like for the other ones, lines 284-305).\n\nAlso making a string as generic as \"%s:\" translatable can lead to \ntranslation errors because this has the structure of sentence lego where \nwe can be sure that the %s is another translated string.\n\n\n"},{"id":"453504","messageId":"xmqqa6cp9bfo.fsf@gitster.g","threadId":"57708","inReplyTo":"10867692-7c2b-1f89-d575-3d9b6e696a24@free.fr","subject":"Re: [PATCH] Make a colon translatable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-13T16:48:27Z","receivedAt":"2022-04-13T16:48:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël Avila <jn.avila@free.fr> writes:\n\n> Just to chime in, I would tend to approve Julien's proposal, but with\n> a reworded commit message, which should convey that the segment to \n> translate is not a full sentence.\n\nThanks.  I think that is probably a sensible thing to do.  The use\nof \"%s:\" (or \"%s\") is necessitated by the use of status_printf_ln()\nin\n\n    status_printf_ln(s, c, \"%s\", what);\n\nand if we had status_puts() instead, we wouldn't be having this\ndiscussion, as the line would have been\n\n    status_puts(s, c, what);\n\nand it is obvious that \"what\" (aka \"label heading\") wants to have\ncolon after it.\n"}]}