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 localesThis 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
