warning: internationalized messages should not contain the '\v' escape sequence

warning: internationalized messages should not contain the '\v' escape sequence

[Румен Петров]

During the check of 2.30.9000 translation I note again above warning. In 
Bulgarian tab is it is translated as new line.

Please could you update original text to be gettext compliant.

Regards,
Roumen Petrov

Re: warning: internationalized messages should not contain the '\v' escape sequence

[Rafal Luzynski]

12.01.2020 12:59 Румен Петров <transl@roumenpetrov.info> wrote:
> During the check of 2.30.9000 translation I note again above warning. In 
> Bulgarian tab is it is translated as new line.
> 
> Please could you update original text to be gettext compliant.

According to the documentation it is:

   "A descriptive string about this program; if it contains a
    vertical tab character (\v), the part after it will be
    printed *following* the options"

which means that character is necessary in this place and should
be preserved by translators.  What kind of warning can you see?
Is it OK if we just ignore the warning?

Regards,

Rafal

Re: warning: internationalized messages should not contain the '\v' escape sequence

[Румен Петров]

Rafal Luzynski wrote:
> 12.01.2020 12:59 Румен Петров <transl@roumenpetrov.info> wrote:
>> During the check of 2.30.9000 translation I note again above warning. In
>> Bulgarian tab is it is translated as new line.
>>
>> Please could you update original text to be gettext compliant.
> 
> According to the documentation it is:
> 
>     "A descriptive string about this program; if it contains a
>      vertical tab character (\v), the part after it will be
>      printed *following* the options"

Hmm interesting, I cannot see in 
https://www.gnu.org/software/gettext/manual/gettext.html .


> 
> which means that character is necessary in this place and should
> be preserved by translators.  What kind of warning can you see?

Please see mail subject, i.e. warning: internationalized messages should 
not contain the '\v' escape sequence.


> Is it OK if we just ignore the warning?

:) Warning is warning. Question when warning is supposed to block a 
process is out of scope to this thread.


Let me quite gettext manual (see url above):
...
Another example is the ‘argp’ convention to use a single ‘\v’ (vertical 
tab) control character to delimit two sections inside a string. This is 
flawed. Some translators may convert it to a simple newline, some to 
blank lines. With some PO file editors it may not be easy to even enter 
a vertical tab control character. So, you cannot be sure that the 
translation will contain a ‘\v’ character, at the corresponding 
position. The solution is, again, to let the translator translate two 
separate strings and combine at run-time the two translated strings with 
the ‘\v’ required by the convention.
...


> 
> Regards,
> 
> Rafal
> 


Regards,
Roumen Petrov

Re: warning: internationalized messages should not contain the '\v' escape sequence

[Siddhesh Poyarekar]

On 18/01/20 7:39 pm, Румен Петров wrote:
>> which means that character is necessary in this place and should
>> be preserved by translators.  What kind of warning can you see?
> 
> Please see mail subject, i.e. warning: internationalized messages should
> not contain the '\v' escape sequence.

I see this too when I do a msgmerge.

>> Is it OK if we just ignore the warning?
> 
> :) Warning is warning. Question when warning is supposed to block a
> process is out of scope to this thread.
> 
> 
> Let me quite gettext manual (see url above):
> ...
> Another example is the ‘argp’ convention to use a single ‘\v’ (vertical
> tab) control character to delimit two sections inside a string. This is
> flawed. Some translators may convert it to a simple newline, some to
> blank lines. With some PO file editors it may not be easy to even enter
> a vertical tab control character. So, you cannot be sure that the
> translation will contain a ‘\v’ character, at the corresponding
> position. The solution is, again, to let the translator translate two
> separate strings and combine at run-time the two translated strings with
> the ‘\v’ required by the convention.
> ...
> 

This should be easy enough to fix in gencat.c once glibc master opens up
in February.

Siddhesh

Re: warning: internationalized messages should not contain the '\v' escape sequence

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On Sat, 18 Jan 2020, Румен Петров wrote:

> Let me quite gettext manual (see url above):
> ...
> Another example is the ‘argp’ convention to use a single ‘\v’ (vertical tab)
> control character to delimit two sections inside a string. This is flawed.

I don't see any real difference from e.g. printf format strings.  In both 
cases, there are conventions the string is following that the translated 
string has to follow as well.  What this suggests to me is that there 
should be a way to mark up a string as using the \v convention for gettext 
to verify that the translation follows the same convention, just as it can 
verify that printf formats are consistent between original and translated 
strings.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: warning: internationalized messages should not contain the '\v' escape sequence

[Siddhesh Poyarekar]

On 20/01/20 11:40 pm, Joseph Myers wrote:
> I don't see any real difference from e.g. printf format strings.  In both 
> cases, there are conventions the string is following that the translated 
> string has to follow as well.  What this suggests to me is that there 
> should be a way to mark up a string as using the \v convention for gettext 
> to verify that the translation follows the same convention, just as it can 
> verify that printf formats are consistent between original and translated 
> strings.

It sounded to me like this was more of a case where translation tools
(and hence, translators) are not consistent in their support of \v and
hence there is a likely variation across translations.  Requiring
translators to manually patch up files is an inconvenience that is
probably not worth it since the parts delimited by \v don't have to
strictly be together, i.e. they could be split into multiple strings and
not lose context for translators.

Siddhesh