[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
- Re: Coordination on standardizing gettext() in future POSIX, Joerg Schilling, 2020/01/21
- Re: Coordination on standardizing gettext() in future POSIX, Bruno Haible, 2020/01/21
- Re: Coordination on standardizing gettext() in future POSIX, Joerg Schilling, 2020/01/22
- Re: Coordination on standardizing gettext() in future POSIX, Joerg Schilling, 2020/01/23
- Re: Coordination on standardizing gettext() in future POSIX, Bruno Haible, 2020/01/24
- Re: Coordination on standardizing gettext() in future POSIX, Joerg Schilling, 2020/01/24
- About printf %2$s (Was: Coordination on standardizing gettext() in future POSIX), Stephane Chazelas, 2020/01/31