AcceptEnv LANG LC_* vs available locales

[Jochen Bern]

On 01.05.22 01:07, Thorsten Glaser wrote:
> On Sun, 1 May 2022, Jochen Bern wrote:
>> If that's your opinion, go ahead and implement it. Which my suggestion of a
>> server-side helper evaluating the client-side-set and server-side-available
>> locales
> 
> This could be… challenging. (There’s locale(1) -a, sure, but…)

Which part of it, a) getting the locally known locales, b) verifying 
that they're indeed *operational* (OS knows it but your main app doesn't 
support it), and/or c) selecting a compromise from them?

If a) and/or b), then that's already a problem in and of itself. What 
good is locale support on just this *one* machine, not even doing any 
remote connections, if the user has difficulties to pick the one he can 
and wants to use?

(OK, we *are* talking about *human languages*. How many Germans, faced 
with all "DE" locales being somehow missing/defunct, would know that 
"Ripuarian" is actually a family of German dialects, and will likely be 
mostly understandable to them ...)

c) is the problem we're trying to solve. Eggs, omelette. ;-)

> It also assumes locale support on both ends in the first place.

If the *client* lacks it, I would guess that $LANG and $LC_* are unset, 
will be propagated empty to the server, and not offer any information on 
the client and user whatsoever, with or without an attempt at negotiation.

If the *server* lacks it, there's no point in trying to select one on 
the server side, anyway. The user will be faced with whatever passes as 
the server's one and only locale, whether it's Greek to him or not.

>> I expect terminals to gravitate more and more towards implementing
>> it, increasing the pressure on the consortium to include two codepoints to
>> "shift to control" and "shift back" into its standards, laying the groundwork
>> of a *global* algorithm for terminals to tell control data from content.
> 
> I highly doubt anything will change now, especially things that break
> compatibility.

How would the Unicode Consortium allocating two codepoints for *this* 
purpose be any *more* prone to "breaking compatibiliy" than the 
expansion of the emoji list every dozen months or so already is?

Quite to the contrary, it would open the possibility to have the server 
side modify its emitted data from

<prnChar> <prnChar> <termCtl> <prnChar> <prnChar> ...

to

<prnChar> <prnChar> <toCtl> <termCtl> <toText> <prnChar> <prnChar> ...

so that a terminal aware of the <toCtl> and <toText> characters could 
recognize <termCtl> as a control sequence *even if the sequence is not a 
proper one for this term at all*.

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220502/68c55e29/attachment-0001.p7s>