bug-gnulib
[Top][All Lists]
Advanced

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

Re: Please do not install a charset.alias file under Mac OS X


From: Vincent Lefevre
Subject: Re: Please do not install a charset.alias file under Mac OS X
Date: Mon, 19 Jan 2009 04:01:40 +0100
User-agent: Mutt/1.5.19-vl-r26315 (2009-01-14)

On 2009-01-18 21:41:37 +0100, Bruno Haible wrote:
> Hello Vincent,
> 
> You brought up two different issues:
> 1) The fact that config.charset for MacOS X recognizes only UTF-8 locales.
> 2) The conflicts when packaging software sees a charset.alias file that
>    belongs to different packages.
> 
> Ad 1)
> Vincent Lefevre wrote:
> > > You are better off filing this report against gettext, which is the
> > > source of this file, and/or gnulib, which ships the latest version
> > > of this file even in packages (such as m4) that have not yet
> > > undergone the I18n conversion to use gettext.
> > 
> > I've just reported a bug against gettext:
> > 
> >   https://savannah.gnu.org/bugs/index.php?25235
> 
> See my response there. In summary, locales with an encoding other than
> UTF-8 are not supported by MacOS X because filenames MUST be in UTF-8 on
> this platform.

I've replied. I don't use non-ASCII characters in filenames, so that
there's no problem with non-UTF-8 locales. Anyway there would the same
problems under Linux: try to re-read UTF-8 encoded filenames (e.g.
created by a graphical application or by another user) under non-UTF-8
locales...

> The generated charset is user-editable, though. (That's the very reason
> why charset.alias is a separate file.) You can edit it as you like.

But the default file makes utilities fail to give correct messages
under non-UTF-8 locales, whereas without this file, there are no
problems at all (whatever locales are used).

> I hardcoded the contents of charset.alias for glibc systems, so as to
> avoid such conflicts for RPM and Debian packaging tools. Shall I do
> the same for MacOS X? It will resolve the problem with the conflict,
> but users will then not be able to customize the file.

I don't see why they would need to customize it.

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)




reply via email to

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