Hacker News Reader

Supporting "every single language, culture, format" *is" the task in the article. You can decide whether you want to do it or not, but that's a different question.

But who thinks that's simple? That's an insanely complex task.

At a high level the task may seem simple "Wrap the text when it reaches the end of the line". And if you only care about English, it actually is reasonably simple. The complexity is stuff you wouldn't even think about unless you had experience in the area.

Fair, to a point.

But colordrops said "supporting every single language, culture, format". So by definition, it's more than English. And as soon as you start looking into non-English writing systems, you realize that it is very much not simple.

indeed, once a task includes 'every', it's never simple.

Or 'never' :-)

We were looking at internationalization and translations recently and I was happily surprised when the guy who is normally a strict stickler for everything being perfect just said "No, we really don't want to do that."

Our software deals with scientific stuff and safety stuff, and even a minor mistranslation there could have a big (and potentially very bad) impact.

So even though technically we could allow translations, we don't, and there's a very good reason for that. Human languages are messy, and every time you switch from one to another, there's a good chance of something getting lost along the way. And sometimes, that kind of loss is just not acceptable. Even if it would be a little more convenient.

Drawing the limits and knowing when to say "no", even to what might seem like a 'simple' thing, is important.

The problem with translations is that even the best translators can make mistakes because when you just send them a list of strings they are unaware of the context where these will be used. And then you end up with "Key" being translated as "Taste" (key on a keyboard) instead of "Schlüssel" (which would have been appropriate in the Windows Registry Editor) in German. So the translator should be:

* fluent in both languages (including domain-specific tech lingo)

* intimately familiar with the software

* very thorough (has to ideally check each and every string if it works in the context of the software)

...only then will you get a high quality translation.

This certainly may work in some contexts. But it won't for others. For example if I am a heavy machinery operator and I see some warning that is not in my native language, I may just ignore it.

> if you want to support every single language, culture, format, then it becomes a very long task.

HAH! Even if you just say "I only support English", "text handling" is still an infinite black hole of programming time and energy.

Rendering text sucks.

  > it seems like for the smaller to mid scale software projects, I18n is just not worth it

If you don't mind reading from right to left and praying towards Mecca, then sure you can disregard all the diversity of human accomplishment. But unless you are willing to have another language and culture imposed on you, suggesting that you imposing your language and culture on others is "worth it" as opposed to wrapping all user-facing strings with some gettext-compatibility layer is disingenuous.

I write i18n compatible software, that supports not only multiple languages but also interface directionality and culture-specific features. Not because I have to, but because I respect my users.

> the end result is so bad that native speakers would rather just use the app in correct English than broken native language

Is that actually supported by evidence or did you pull it out from .. somewhere?

This claim probably holds if the user is fluent in English as a second language, but are you sure the billions of people who can't read English would really make that choice?

I think it's the developer's choice whether to only support users that can read English to at least some degree, but claiming that an option for broken i18n is worse than nothing seems to be rather radical to me... (that said, the number of websites that presume my language preferences upon a geoip check is infuriating...)

Agreed, it shouldn't be unreasonable to expect everyone to learn Mandarin Chinese, or perhaps Spanish?

[0] https://en.wikipedia.org/wiki/List_of_languages_by_number_of...

I think it would be a better idea to focus on the total number of speakers, or even second language speakers [1]. For example, English has 372 millions first language speakers and 1 billion second language speakers. Mandarin Chinese has 929 millions first language speakers and 198 millions second language speakers. This means that way more people have learned English as a second language. This, I would assume, would mean that it's generally easier to learn, there are more infrastructures/people in place to do it, people are more used to second language speakers, and it's in general a better language to communicate across cultures.

[1]: https://en.wikipedia.org/wiki/List_of_languages_by_total_num...

English is somewhat better than Chinese because it’s easier to learn and has more total speakers, but 1.4 billion people is still pretty far from 7+ billion people. Choosing to only offer something in English _and_ make it difficult or impossible to translate it in other languages is telling 5.6 billion people they don’t matter until they learn the language you happen to speak.

I mean, if they could do the things listed in the article for the original gameboy, I’m inclined to believe we should be able to do them today.

Now I sped through the article a bit, but afaik the Gameboy did not have native support for html rendering and webgl...

Construct is a game engine so they need to support everything.