4 ms·
OMG this is so cool to a person who lives in the CJK world (to be specific, I’m Korean) where the order of noun/verb/adj is reversed and always gets to see prog
by pcr910303 8y ago
OMG this is so cool to a person who lives in the CJK world (to be specific, I’m Korean) where the order of noun/verb/adj is reversed and always gets to see programs that display text something like ‘Site is news reader HN’, ‘Button press confirm to’.
It’s a pity that the programming world is still super bad at i18n :-(
- chungleong 8y agoIt won't help much with Chinese localization, where the persistent problem is that developers assume every language has the words "yes" and "no".
- themacguffinman 8y agoDoesn't Chinese have understandable localizations for affirmative/negative responses like "是" and "没有"? I don't see the problem.
- chungleong 8y agoThat's roughly like putting [OK] and [Cancel] into a dialog box that asks "Do you want to save this document?". Perfectly understandable but awkward, somewhat confusing to non-tech people--in a word, unfluent. Answering such questions in Chinese (and I imagine, in Welsh) requires the verb that was used in the question.
- zbraniecki 8y agoHi! This is also a problem in Welsh [0]. In the Fluent world we solve that on the level of design principles (do not reuse the string `yes` because it can be translated to a different `yes` in different buttons) and bindings (compound messages allow us to localize a whole widget with a main message and its yes/no options). [0] http://psychopixi.com/languages/yes-and-no/ http://psychopixi.com/languages/yes-and-no/
- zoul 8y agoI18n is something like security, it takes a lot of effort to get right, people often don’t know that their assumptions are subtly wrong, and getting them right often requires using a more complicated solution. No wonder programmers just cop out and settle for ASCII, naïve string comparisons, first name & surname fields, etc. And the problems go quite deep, all the way down to standard libraries and programming languages. The Swift debate about correct and performant Unicode string processing was very interesting – people are very hard to convince that string is not a collection of characters randomly accessible with integer indexes.
- anbop 8y agoHow much money is a company losing because its Korean string is nonsense?
- Khol 8y agoThink about how often the english documentation coming with cheap products from china is mocked - do you really want your professional output to be treated in the same regard?
- cpfohl 8y agoNo, but if it comes down to writing better translation code, or adding features and bug fixes, I know where my clients typically land.
- Khol 8y agoIf you're writing translation code then you're (probably) doing it wrong. If your clients are happy to only ever have a product in one language which will never have to deal with anything outside the 7bit ascii range then ignoring the complexity required to do it is (probably) fine. As soon as you hit some requirement which violates the above if you haven't considered how this might affect you you're likely in for some horrible problems when suddenly you need to handle these things.
- wccrawford 8y agoI'm an English native speaker that dabbles in other languages occasionally, and I know enough to recognize possible problem areas, but not enough to actually do anything about them. The complexity of this Fluent library shows what a massive problem it is. I'm not surprised that we continue to be this bad at it.