I18n 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.

I'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.

It won't help much with Chinese localization, where the persistent problem is that developers assume every language has the words "yes" and "no".

Hi! 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/

Doesn't Chinese have understandable localizations for affirmative/negative responses like "是" and "没有"? I don't see the problem.

That'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.

How much money is a company losing because its Korean string is nonsense?

Think 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?

No, but if it comes down to writing better translation code, or adding features and bug fixes, I know where my clients typically land.

If 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.