[PATCH] fetch-pack: add TRANSLATORS notice for packfile ready messages

[PATCH] fetch-pack: add TRANSLATORS notice for packfile ready messages

[Bagas Sanjaya]

Two messages mention "... to be sent after 'ready'". The 'ready' string,
however, is actually in part of packet stream, which shouldn't be
translated. Because of lack of any notices, l10n teams treat it as
ordinary string, which results to inconsistency across teams. That is,
in `po/es.po` the string is translated:

```
msgid "expected packfile to be sent after 'ready'"
msgstr "se esperaba que el packfile fuera enviado luego del 'listo'"

msgid "expected no other sections to be sent after no 'ready'"
msgstr "se esperaba que ninguna otra sección fuera enviada luego del 'listo'"
```

whereas in `po/fr.po` and `po/de.po`, the string isn't translated:

```
msgid "expected packfile to be sent after 'ready'"
msgstr "fichier paquet attendu à envoyer après 'ready'"

msgid "expected no other sections to be sent after no 'ready'"
msgstr "aucune autre section attendue à envoyer après absence de 'ready'"
```

```
msgid "expected packfile to be sent after 'ready'"
msgstr "Erwartete Versand einer Packdatei nach 'ready'."

msgid "expected no other sections to be sent after no 'ready'"
msgstr "Erwartete keinen Versand einer anderen Sektion ohne 'ready'."
```

To avoid confusions, add TRANSLATORS notice.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 fetch-pack.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fetch-pack.c b/fetch-pack.c
index a9604f35a3..0cda8fc518 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1410,8 +1410,12 @@ static int process_ack(struct fetch_negotiator *negotiator,
 	 * otherwise.
 	 */
 	if (*received_ready && reader->status != PACKET_READ_DELIM)
+		/* TRANSLATORS: 'ready' string is in part of packet stream.
+		   Leave it as is. */
 		die(_("expected packfile to be sent after 'ready'"));
 	if (!*received_ready && reader->status != PACKET_READ_FLUSH)
+		/* TRANSLATORS: 'ready' string is in part of packet stream.
+		   Leave it as is. */
 		die(_("expected no other sections to be sent after no 'ready'"));
 
 	return 0;

base-commit: 6c220937e2b26d85920bf2d38ff2464a0d57fd6b
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] fetch-pack: add TRANSLATORS notice for packfile ready messages

[Ævar Arnfjörð Bjarmason]

On Sun, Nov 14 2021, Bagas Sanjaya wrote:

> Two messages mention "... to be sent after 'ready'". The 'ready' string,
> however, is actually in part of packet stream, which shouldn't be
> translated. Because of lack of any notices, l10n teams treat it as
> ordinary string, which results to inconsistency across teams. That is,
> in `po/es.po` the string is translated:
>
> ```
> msgid "expected packfile to be sent after 'ready'"
> msgstr "se esperaba que el packfile fuera enviado luego del 'listo'"
>
> msgid "expected no other sections to be sent after no 'ready'"
> msgstr "se esperaba que ninguna otra sección fuera enviada luego del 'listo'"
> ```
>
> whereas in `po/fr.po` and `po/de.po`, the string isn't translated:
>
> ```
> msgid "expected packfile to be sent after 'ready'"
> msgstr "fichier paquet attendu à envoyer après 'ready'"
>
> msgid "expected no other sections to be sent after no 'ready'"
> msgstr "aucune autre section attendue à envoyer après absence de 'ready'"
> ```
>
> ```
> msgid "expected packfile to be sent after 'ready'"
> msgstr "Erwartete Versand einer Packdatei nach 'ready'."
>
> msgid "expected no other sections to be sent after no 'ready'"
> msgstr "Erwartete keinen Versand einer anderen Sektion ohne 'ready'."
> ```
>
> To avoid confusions, add TRANSLATORS notice.

Let's not and:

> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  fetch-pack.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index a9604f35a3..0cda8fc518 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -1410,8 +1410,12 @@ static int process_ack(struct fetch_negotiator *negotiator,
>  	 * otherwise.
>  	 */
>  	if (*received_ready && reader->status != PACKET_READ_DELIM)
> +		/* TRANSLATORS: 'ready' string is in part of packet stream.
> +		   Leave it as is. */
>  		die(_("expected packfile to be sent after 'ready'"));
>  	if (!*received_ready && reader->status != PACKET_READ_FLUSH)
> +		/* TRANSLATORS: 'ready' string is in part of packet stream.
> +		   Leave it as is. */
>
>  		die(_("expected no other sections to be sent after no 'ready'"));

If something isn't meant to be translated do this instead:

    die(_("expected no other sections to be sent after no '%s"), "ready");

I.e. pass it as a parameter.

There can then be a "TRANSLATORS" comment that explains that it's the
string "ready", in reference to that protocol keyword. We do it that way
in various other places, and it completely avoids the potential problem
of a should not be translated string being translated.

Re: [PATCH] fetch-pack: add TRANSLATORS notice for packfile ready messages

[Bagas Sanjaya]

On 14/11/21 16.50, Ævar Arnfjörð Bjarmason wrote:
> If something isn't meant to be translated do this instead:
> 
>      die(_("expected no other sections to be sent after no '%s"), "ready");
> 
> I.e. pass it as a parameter.
> 
> There can then be a "TRANSLATORS" comment that explains that it's the
> string "ready", in reference to that protocol keyword. We do it that way
> in various other places, and it completely avoids the potential problem
> of a should not be translated string being translated.
> 

Something like:
/* TRANSLATORS: The 'ready' string is the protocol keyword. Leave it
    as is. */ ?

But I have admitted that I lean to your suggestion.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] fetch-pack: add TRANSLATORS notice for packfile ready messages

[Ævar Arnfjörð Bjarmason]

On Mon, Nov 15 2021, Bagas Sanjaya wrote:

> On 14/11/21 16.50, Ævar Arnfjörð Bjarmason wrote:
>> If something isn't meant to be translated do this instead:
>>      die(_("expected no other sections to be sent after no '%s"),
>> "ready");
>> I.e. pass it as a parameter.
>> There can then be a "TRANSLATORS" comment that explains that it's
>> the
>> string "ready", in reference to that protocol keyword. We do it that way
>> in various other places, and it completely avoids the potential problem
>> of a should not be translated string being translated.
>> 
>
> Something like:
> /* TRANSLATORS: The 'ready' string is the protocol keyword. Leave it
>    as is. */ ?

No, e.g. "TRANSLATORS: The parameter will be 'ready', a protocol
keyword" or something.

I.e. you don't need to instruct them to leave it as-is if there's no way
they can't leave it as-is, since it's being passed as a parameter.

> But I have admitted that I lean to your suggestion.

Yes you could also embed it in the string, but why do that in this case?
Seems like zero benefit, and potential translator confusion.