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 <[email protected]> - 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)
