Redox i18n goals and ideas
Created by: msikma
This is related to #800. The lack of a GNU gettext style project is obviously the first step towards internationalization, but I think it might be useful to look at the issue from a higher level as well. I18n is a hard problem. What can we learn from and improve upon other OSes?
These are just my own thoughts as a speaker of multiple languages. Redox is a new operating system being developed from scratch, and as such it's in a position to build a very solid foundation for multiple languages. My hope is that this can spark a discussion and maybe yield some useful design principles, even though development is in a very early stage.
Some considerations, in no particular order:
- Most obviously, there is a need to include fonts to render glyphs from many different languages. If possible, fonts that are somewhat consistent since it's common for languages of a non-Latin script to appear alongside Latin characters.
umount: /media/cdrom0: umount failed: 許可されていない操作ですor in many other cases.
- It's useful to switch languages on the fly, as in Mac OS X (actually, it's had this since OpenStep!) On OSX, a process remains the language it was started in, so programs need to be restarted to see the changes. (OSX offers to restart the computer when changing languages.) This is understandable, but it would be nice if it could be possible to simply tell programs to reload translation strings and re-render. This is becoming increasingly common in web apps.
- On that note, it may be desirable to run specific programs in different languages (and more generally, with different localization settings). On OSX this is technically possible, but there is no UI support for it.
- It's hard to get non-Latin characters to display in a virtual console (i.e. a completely text mode terminal outside the window manager). For example, on a clean install of Debian using Japanese from step one of the installation script—although the entire installer uses Japanese just fine—the resulting system cannot display Japanese text inside a virtual console. This breaks filenames and error messages, which are all replacement characters. (Maybe it's not possible, even. As far as I can tell, PSF fonts don't support more than 512 characters.) It's expected that users will need to dive into the terminal in some situations (preferably not as often as is the case for Linux, though), which makes full internationalization support in this area something to consider.
- A platform such as Ubuntu Launchpad would be invaluable for translations. Centralizing translations is essential to minimizing breakage. Taking Debian as example again, depending on whether I choose MATE or Gnome Classic as the window manager, logging out will have either an English or a Japanese version of the "restarting in 60 seconds" progress bar. It's not such a big deal for things to be incomplete, but where does one go to fix this? Having a single authoritative answer that goes for at least all translatable in-house Redox projects would go a long way towards preventing gaps.
- Scripts that are more complex than Latin are sometimes preferable in a larger font size than normal. These days screens are a bit bigger and better, so this isn't as much a problem as it was in the past. Especially on high dpi displays. Still, in such cases it's likely preferable that changing the language increases the base font size, rather than requiring the user to go to a different control panel to increase the font size separately. I'm not certain this is really a necessity though, but I'm mentioning it here for completeness.
- Languages that use a non-Latin script usually contain Latin characters. This means the default font for Latin text is different. E.g. see this English article when using English as the system language, and when using Japanese. Keeping the default Latin font is probably preferably. For comparison, see how the Finder combines Latin and Japanese much more nicely.
- Right-to-left languages are such a hard problem that I can't even begin to think about it. I don't know any RTL languages, so there's not much I can say, except that the few times I've worked with them on the web I was pleasantly surprised by how well CSS's Flexbox model works for LTR and RTL. (It doesn't use the words "left" and "right", but only "start" and "end". When switching to RTL, those two words have their definitions changed.) This might be a clue towards building support for LTR/RTL agnostic UI.
Input is another hard problem, probably worth a completely separate discussion. I'll note at least that it's a bit disorienting to have no access to an IME when inside a virtual console. This could potentially make it very difficult to rescue a system if a user depends on it for input. In graphical environments, the currently existing solutions for input are I think quite good.