Example of precedent: 1. deprecation of STREAMS for implementing networking services and other character-based I/O, 2. support for DEFLATE in compress (bug 1041, my proposal originally), 3. recognition of emacs in rationale
For 1, it's a case of recognition of obsolescence that led to a normative decision; for 2, it's a recognition of advancement in technology that led to adoption by standard; however, since language models are too radical a new technology, I think it's more likely we just recognize it like 3. > 2025年5月30日 09:01，Niu Danny <danny...@hotmail.com> 写道： > > As I said in the previous thread, language models are > more powerful than locale definitions in terms of > providing culture-familiar user experiences. > > Defining additional is optional (requiring the POSIX2-LOCALEDEF symbol) > and I think this is right, as not all implementations > can afford to support it if they don't need it > (e.g. embedded, real-time, or some bare-metal systems). > > There's also the issue of localedef doesn't support > lock-shifting character sets. The importance of these > charsets are eclipsed considering UTF-8, yet the same > can be said of localedef considering language models. > > Still, language models are to localdef as > DNSSEC are to plaintext DNS - the formers require > effort in preparation, while the latters are more > readily and immediately available. > > The immediate question of this thread is whether we > want to move localedef to an option group (such as > [UP] - user portability). While the longer discussion > would be how do members of this group see language > models verses localedefs in the context of the standard.
