Martin wrote: > > Quite a few people might expect their Japanese filenames to appear with a > Japanese font/with Japanese glyph variants, and their Chinese filenames to > appear with a Chinese font/Chinese glyph variants. But that's never how this > was planned, and that's not how it works today. >
It's not necessarily "how it works today", although making it work properly does require forethought and your observation is generally true. However, there certainly are products (I can think of several ;-)) that make or try to make this distinction and draw (for example) Chinese and Japanese using language-specific fonts/glyph selection in isolation from the system locale. I do, however, agree with you that Latvian vs. Marshallese is a much less likely case (smaller speaker populations widely divided geographically) and one that people working on language specific rendering are less likely to pay attention to (or even notice). Solving the Latvian/Marshallese problem is pretty similar to solving the Chinese/Japanese one, though. Somewhere else in the reply, someone said: > > >> Only the language that the user care about matters, and this can be easily > inferred from the system locale, and passed down to the text rendering stack. > > The system locale is only a hint of what the user cares about and even monolingual users will access files or content that uses a wide range of characters or languages. There is also the problem that you're unlikely to be running your software in a Marshallese locale (or have another such external hint). The real issue is the need for language metadata in file formats and other places to enable language-specific rendering to take place. Lacking language metadata, you get what you get. Addison Addison Phillips Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture.
