Re: Bug#196637: gettext: xgettext messes with control characters (fwd)

[Göran Weinholt]

On Tue, Jun 10, 2003 at 08:24:17PM +0200, Bruno Haible wrote:
> Göran Weinholt wrote:
> 
> > xgettext has been changing \v to ^K for some time now. Please make it
> > stop.
> >
> > $ echo 'gettext("This ->\v<- is a \\v.\n")'|xgettext -L c -o - -|tail -3
> > #: standard input:1
> > msgid "This ->
> >               <- is a \\v.\n"
> > msgstr ""
> 
> If you want a C-like escape sequence in the POT file you can use the option
> --escape for this purpose:
> 
> $ echo 'gettext("This ->\v<- is a \\v.\n")'|xgettext -L c --escape -o - 
> -|tail 
> -3
> #: Standardeingabe:1
> msgid "This ->\013<- is a \\v.\n"
> msgstr ""

This feature would be more useful if it could be made to only escape
control characters, and if you could pass -E to msgmerge via Makevars.
It isn't exactly what I want, but ...

> > Is there any good reason for this? It makes the translators job harder
> 
> Maybe the program's author could try to avoid the control character \v
> in his translatable strings? Most translators will have problems with this.
> I'd not recommend using such control characters in strings that get
> translated.

... I guess you're right. The only reason \v is used here is because
it's very unlikely to be used for anything else, so you gain a little
speed by skipping a few checks.

> > since \n and possibly other control characters
> > aren't treated the same way.
> 
> This inconsistency is because \v is less standard (a more recent invention)
> than \n and \b.
> 
> The same holds for \a.

That explains that. Thanks for your patience, this message closes the bug.

-- 
Göran Weinholt <address@hidden>
GPG: 1024D/4A8854E6 EC27 7F6A DFA9 CBBD 9EE3  F07A 8DF5 8BB6 4A88 54E6
"Science does not remove the terror of the Gods."  -- J.R. "Bob" Dobbs