Re: [PATCH] helpfiles: Also accept 'UTF-8' as an encoding name.

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2013-11-14 at 07:50 +0000, Martin Vaeth wrote:
> Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
> >> perhaps also be checked) there are besides de_* also fy_DE and hsb_DE on
> >> a Debian installation at my institute (though I do not know what
> >> they mean).
> >
> > ISO 639 language code, followed by ISO 3166 region tag identifying a
> > regional dialect.
> 
> Thanks for the information. That it is some sort of German dialect
> spoken somewhere else was clear to me, that's why I think it *might*
> be a possible fallback.

Back to the point being raised, which I was addressing without being too
direct, in an attempt to be a little tactful: Bart is right, the
language code does need to be anchored ("^en").  The fact that "de" can
appear in two places in the examples you cite does not mean it should be
_accepted_ in either; "de_" is "German", "_DE" is "Germany".

Looking more closely, I'm confused: why do we care which character sets
are available, and why are we not just setting `LC_ALL=C` during the
generation?  We're making plain-text files, not stored in a
charset-dependent hierarchy, from a source under our control which has a
limited set of possible outputs.  It seems the only changes likely to be
made, depending upon character set, relate to the various hyphen/dash
options (where it's highly likely we want to force HYPHEN-MINUS from
traditional ASCII, to be sure that options shown can be copy/pasted
without worrying about man/groff macro variants and what dash might have
been chosen).

The commit message and ChangeLog additions are rather short on details,
since they only talk about the change causing the helpfiles to be
generated and don't mention anything about the addition of locale
fiddling.

-Phil