don't forget that full internationalization also includes taking care of layouting issues i.e. words that are longer in other languages. Characters that are higher.
Right to left text.
> Probably not something international software is aware of.
Collation rules that vary by locale exist for this reason, and all major programming languages and OS'es support this. Of course whether the software you use does this or not depends on the developers writing the software.
I'm not saying it shouldn't be in international English, it definitely should. It just takes a bit of getting used to if that's not how you write already.
I'm not sure "international" is the right characterisation (sorry, not sorry). "Non-ASCII", perhaps? Or explicitly list which codepages you do support?
It's not like there are no people in the US who use characters with accents. Or, indeed, that everyone reading your comment considers themselves to be "international".
Simply out of curiosity for this same topic, do you happen to know of a good resource for finding out even just some of the less trivial differences that this solves? I'm sure it does but off hand I don't know them (I'm not all that multilingual).
I understand it'll bring in glyph orderings that don't exist in en_US or whatever you've got the default set to, such as 'Ç' in french among others.
Don't ever use the original string as key in the localization table. That will force you to translate "high" difficulty the same as "high" resolution, for example.
You mean c2sup? Either way I create unnecessary confusion to save typing one character? Not worth it. I'm not a fan of i18n but at least it has a purpose.
reply