bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coordination on standardizing gettext() in future POSIX


From: Bruno Haible
Subject: Re: Coordination on standardizing gettext() in future POSIX
Date: Wed, 22 Jan 2020 13:07:56 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

Joerg Schilling wrote:
> It is obvious that gettext(1) must expand escape sequences by default since 
> this is the documented default behavior for both Solaris gettext(1) and GNU 
> gettext(1) but in the default case, GNU gettext does not behave the way it is
> documented. 

What you call the "GNU gettext documentation" is [1], the ambiguous LI18NUX
specification (which, by the way, was a common effort of Sun Microsystems
people and GNU people).

The actual GNU gettext documentation is here: [2], and the part about the
escape sequences has not changed since 2004. GNU gettext behaves the way
it is documented: It does NOT expand escapes by default.

> You forgot to mention that it also mentions:
> 
>        -n  Suppress trailing newline.
> 
> which makes it obvious that someone made a mistake while writing the GNU 
> documentation that describes the options.

Correct, and I fixed this documentation mistake four months ago. [3]

> given that GNU gettext even copied 
> this text from SunOS man pages from the early 1990s, it is obvious that the 
> intention of the GNU gettext implementation was to be compatible with the 
> reference implementation and there is only a bug in the GNU implementation. 

It is well-known that the escape sequence expansion in 'echo' was different
in System V and BSD systems. You can assume that when Ulrich Drepper started
out writing GNU gettext in 1995, he did NOT want to copy the System V behaviour
of 'echo' into the 'gettext' program.

> > 2) GNU gettext(1) and Solaris gettext(1) differ in this respect:
> >
> > GNU:
> > $ gettext 'abc\ndef'; echo
> > abc\ndef
> >
> > Solaris:
> > $ gettext 'abc\ndef'; echo
> > abc
> > def
> >
> > This makes it hard to standardize, since the behaviours differ, and
> > both implementations will want to claim need for backward-compatibility.
> 
> Well people who expect the current GNU behavior obviously rely on a bug in 
> the 
> implementation.

This argument fails because you were looking at LI18NUX, not at the
documentation of GNU gettext.

> > 3) Additionally, there's the problem that gettext(1) does not and can not
> > (as a program) deal with strings that contain placeholders. As soon as
> 
> It seems that you missunderstand the way gettext(1) is intended to be used.

This is quite unlikely, because I have been the GNU gettext maintainer for
12 years.

> I see two useful ways to do what you like:
> 
> 1)
> 
>       gettext -s "Hello World" $$

No, this is not a reasonable way to use the 'gettext' program. It violates
the principle "Entire sentences" [4]. In different languages, the number may
need to be embedded into a sentence, rather than at the end of the sentence.

> 2)
> 
>       text=$(gettext 'Hello World $$')
>       eval echo $text
> 
>       or
> 
>       eval echo $(gettext 'Hello World $$')

No, this is not a reasonable way to use the 'gettext' program either. It fails
miserably when the translation of 'Hello World $$' contains a semicolon. Try

  text='Coucou; le monde $$'
  eval echo $text

In general, there is agreement among people writing shell scripts that the use
of 'eval' should be minimized, i.e. that 'eval' should only be used when the
lexical structure of the string being eval'ed can be predicted.

Bruno

[1] 
http://web.archive.org/web/20030428195733/http://www.li18nux.org/docs/html/LI18NUX-2000-amd4.htm
[2] 
https://www.gnu.org/software/gettext/manual/html_node/gettext-Invocation.html
[3] 
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=b0d302e404c4b7c2c59e7609aacff35476a494d8
[4] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]