Re: Coordination on standardizing gettext() in future POSIX

[Shware Systems]

My two cents, I'm more in favor of requiring the -e ala GNU, as a byte stream that may be an escape for the charset of one locale may be plain text in another locale, especially when the encoding of the escape char itself differs. This can complicate editing data files when a pot file is a commented template for non-comment equivalences in po files, as an example workflow. Most editors I've used only permit one charset per file, so such a conflict would show in these. To avoid this I believe would require the standard placing more restrictions on charsets locales may use than now, to ensure portability, but this is not part of the proposal.

---

On Tuesday, January 21, 2020 Joerg Schilling <address@hidden> wrote:

Bruno Haible <address@hidden> wrote:

> Joerg Schilling wrote:

> > From looking at the current manuals available on Linux systems, I propose to

> > start with the manual pages from OpenSolaris since these manual pages seem to

> > be closer from being complete enough for the POSIX standard.

>

> The text from LI18NUX [1] and LSB [2] would be a better starting point.

>

> [1] http://web.archive.org/web/20030608111824/http://www.li18nux.org:80/li18nux2k/

Hi,

are there plans to make GNU gettext(1) complatible to [1]?

Background:

The historic gettext from SunOS did expand escape sequences by default since

1989 and did not have any options at that time. So it is obvious that this is

the default behavior.

[1] describes the same behavior for the no-option case, but GNU gettext(1) does

not expand escape sequences unless the option -e has been specified.

This behavior of GNU gettext(1) is in conflict with the definition in [1],

while Solaris gettext(1) is compliant and disables escape sequence expansion

only with the -s option (unless -e is used at the seme time).

So Solaris behaves like documented in [1] and in the Solaris man pages, while

Linux does not.

Jörg

--

EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin

    address@hidden (work) Blog: http://schily.blogspot.com/

URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'