On Tue, Jul 09, 2013 at 10:53:41PM +0200, Branko Čibej wrote:
> Sorry, I have to ask, useful *how* exactly? There is already a perfectly
> valid workaround for the case that Andreas is talking about, namely,
> relieving scripts authors from the complexity of parsing multi-lingual
> responses. It's just that that perfectly valid workaround happens to not
> be "env LANG=C".
This is not about error messages.
There is another, unrelated problem, that was brought up here:
Namely, if users change locales, they cannot update a working copy
without getting errors or filenames with mixed encodings.
Users might have to change locales e.g. when working remotely
on a system that doesn't support the initially chosen locale,
or when working with a text console that doesn't support, say, UTF-8.
> Why invent another configuration knob that you already know (given the
> rest of your post) is going to cause all sorts of trouble?
I think in this case, if users use the knob and run into trouble,
they get to keep the pieces. We'd just be giving them a way to
use a working copy with a specific filename encoding independenly
of the currently active lcoale.
And I'm not going to go out of my way for adding such a feature.
All I'm saying is that I wouldn't object to it in principle.
Received on 2013-07-09 23:04:24 CEST