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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rafal Luzynski
12.01.2020 12:59 Румен Петров <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Румен Петров
Rafal Luzynski wrote:

> 12.01.2020 12:59 Румен Петров <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
In reply to this post by Румен Петров
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
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