Re: non-ASCII characters in /etc/locales.alias ?
(Er, your quoting is a bit confusing; it looks like you're replying to
yourself in places. Parsing and moving stuff around ...)
On Wed, Jan 23, 2002 at 10:53:04AM +0000, Alastair McKinstry wrote:
> > Not really relevant. All files are byte sequences, so this is true by
> > default. Textfiles are *constrained* byte sequences, and this breaks
> > the constraints normally imposed on system textfiles.
>
> I think in context the _locale_aliases_ are byte sequences; they don't
> need to be valid characters in any given locale to work; having them
> undisplayable in various locales is a misfeature, IMHO.
But in a text file, they need to follow text file rules. If they can't
be represented in the proper locale, they need to be represented in some
other way (ie. escapes.)
I'm not sure introducing escapes into locale.aliases would be a good
idea, though. That would mean adding code to help something that
shouldn't be there in the first place. I'd just as soon leave the
problem in place, with appropriate warnings in comments in the file.
> > And "locale -a" should never be outputting anything that's not in the
> > user's charset, nor should any system tool that should know better.
>
> The difficulty is that /etc/locales.alias is a valid text file
> _in_certain_locales_ , but not others; this is a bad idea, especially in
> system files. Tagging it with a coding at least says that "This is a
> valid textfile in encoding ISO-8859-1 and can be edited as such".
With the problems I mentioned; I think the problems outweigh the gain.
I'd hate to see "let's do what they did with locale.alias and stick an
Emacs tag in these files, too!" The tag wouldn't fix locale -a's output
on my UTF-8 terminal, either.
"locale -a" outputting ISO-8859-1 text regardless of the user's locale is
a bigger problem than /etc/locale.alias having them. (Whether or not
anyone ever touches or looks at /etc/locale.alias, people do, will and
are intended to look at locale -a's output.)
> > Is there any need for locale -a to display aliases at all? They're not
> > really locales, they're just aliases *to* locales.
> Compatability with other systems; e.g. Solaris shows the aliases.
> Also, for the few cases (eg "LANG=french evolution") that the user is
> manually selecting a locale name, showing some simple entries like
> "french" rather than just the formal locale names helps the user decide
> what to use.
OK, but this could still be done in locale itself: don't output a locale
alias if the underlying locale isn't actually available.
> > > Hence the "-*- coding: ISO-8859-1 -*-" tag I suggested for locale.alias.
> > > Yes, its emacs specific, but it gets the point across and at least makes
> > > one editor work right. Its a workaround to a misfeature; the
> >
> > It implies the invalid sequences are valid, may encourage this in other
> > files, implies changing this line somehow changes how the file is
> > interpreted by programs (ie. that "locale -a" uses it). If anything
> > should be added, it's something to the effect of "warning: this file contains
> > ISO-8859-1 characters which should not be here; do not do this anywhere else."
> >
> Maybe. I thought this would be covered by the "Warning: this file is
> autogenerated; don't add new entries" comment, though.
Er, was this a reply to the text above it? You refer to "this", but
there were four separate points in that paragraph. Maybe I've been up
too long. :)
A generated textfile follows the same rules as a hand-written one.
If it's autogenerated and says "don't edit this, it's autogenerated",
then there's no need to hint editors in the first place. If all you
want is to not see unsupported aliases in locale -a, I think doing it
within locale is better than autogeneration. (And probably far more
likely to be accepted upstream.)
--
Glenn Maynard
Reply to: