3 ms·

In addition, the whole idea that a system must have a privileged locale is silly in our connected world. Even assuming a single process (which can be talking t

In addition, the whole idea that a system must have a privileged locale is silly in our connected world. Even assuming a single process (which can be talking to endpoints in many countries) should be locked to a specific locale is nonsense. The beauty of LANG=C is that it's the only true lingua franca of modern computing. It's a place where all software and programmers can "meet" without privileging any particular locale. We have 'gettext' and friends for speaking to humans in particular locales. Embedding i18n into core system design just doesn't work.

joshuamorton 7y ago
> Even assuming a single process (which can be talking to endpoints in many countries) should be locked to a specific locale is nonsense. This doesn't matter. I'm not sure why you think this matters or what problems will be caused, but a server using a unicode locale (C.utf8 or en.utf8) doesn't localize things for those clients, it just is able to not crash when printing their usernames to log files.
- downerending 7y ago
  > it just is able to not crash when printing their usernames to log files The usernames could be from a variety of locales. If showing them in that form is seen as valuable, they'll each have to be decoded in their appropriate locale. Using LANG=C doesn't prevent this, it encourages it. Beyond that, as you point out, Unicode provides lots of new opportunities for crashes. Indeed, one of my favorite ways to crash software (software almost invariably running under a "proper" locale) is to feed it a string of (non-ASCII) Unicode. Boom. No matter the approach, you must code for correctness and deal with all input. For Unicode, you must always allow for decoding failure.
  - joshuamorton 7y ago
    > The usernames could be from a variety of locales. If showing them in that form is seen as valuable, they'll each have to be decoded in their appropriate locale. You realize that locales and encodings are different right? En.utf8, c.utf8, and fr.utf8 are all different locales, but are all utf-8 encoded. They'll all work correctly when printed on a machine with any other utf8 locale. The differences arise in things like sort order and regex, where c.utf-8 might be best for a server if you want C or ASCII like functionality. > Using LANG=C doesn't prevent this, it encourages it. Well no, because you don't know what encoding each person is using. Either you guess which is error prone, or you have to control the other endpoint so that they include the encoding. But if you control the client, just use utf-8. Pretty much no software does what you suggest. Go and rust, for example, go further and entirely ignore the system locale and just always use utf-8 for everything. People don't complain.
    - downerending 7y ago
      TIL that there is a "c.utf8". Thank you. But my God, could this shit possibly be any more byzantine? (And why doesn't LANG=C just cause c.utf8 to be used?)

joshuamorton 7y ago

> Even assuming a single process (which can be talking to endpoints in many countries) should be locked to a specific locale is nonsense. This doesn't matter. I'm not sure why you think this matters or what problems will be caused, but a server using a unicode locale (C.utf8 or en.utf8) doesn't localize things for those clients, it just is able to not crash when printing their usernames to log files.

downerending 7y ago
> it just is able to not crash when printing their usernames to log files The usernames could be from a variety of locales. If showing them in that form is seen as valuable, they'll each have to be decoded in their appropriate locale. Using LANG=C doesn't prevent this, it encourages it. Beyond that, as you point out, Unicode provides lots of new opportunities for crashes. Indeed, one of my favorite ways to crash software (software almost invariably running under a "proper" locale) is to feed it a string of (non-ASCII) Unicode. Boom. No matter the approach, you must code for correctness and deal with all input. For Unicode, you must always allow for decoding failure.
- joshuamorton 7y ago
  > The usernames could be from a variety of locales. If showing them in that form is seen as valuable, they'll each have to be decoded in their appropriate locale. You realize that locales and encodings are different right? En.utf8, c.utf8, and fr.utf8 are all different locales, but are all utf-8 encoded. They'll all work correctly when printed on a machine with any other utf8 locale. The differences arise in things like sort order and regex, where c.utf-8 might be best for a server if you want C or ASCII like functionality. > Using LANG=C doesn't prevent this, it encourages it. Well no, because you don't know what encoding each person is using. Either you guess which is error prone, or you have to control the other endpoint so that they include the encoding. But if you control the client, just use utf-8. Pretty much no software does what you suggest. Go and rust, for example, go further and entirely ignore the system locale and just always use utf-8 for everything. People don't complain.
  - downerending 7y ago
    TIL that there is a "c.utf8". Thank you. But my God, could this shit possibly be any more byzantine? (And why doesn't LANG=C just cause c.utf8 to be used?)