| > it makes support Support is already a problem currently, because personalized error messages are less searchable but more useful than generic ones. Moving to error codes is a good example of an orthogonal concern that would incidentally help i18n. Supporting error formats that can be treated by machines is a further unrelated step that would also benefit i18n. So I would say the stuff we already do tend to make this concern less relevant. > reusable code That's an orthogonal concern. You don't write new code when you i18n something, you just create dictionaries. > common understanding, and readability (in a team) I don't believe anyone is making the point that one team should write in separate languages. However, a team able to choose its own language (possibly the one used by the rest of the business) is a plus. In non-english countries, it's very common to have code written in english to describe a business that is done in local language, with really bad translations of business terms. This already causes issues. > increases the amount of development overhead of whomever has to maintain the language. Why would the language maintainer do the i18n themselves? |
No. i18n is not that easy, sorry. I wish it were.
To be frank, this answer reads as though it was written by someone who has not done any extensive i18n work in their life. Languages are not 1:1 translatable. This goes beyond words and phrases - numbers, math, time, dates, names, grammar, etc. are all completely unrecognizable between certain languages.
It's not a problem that even regular software has solved generically and elegantly, and then going on to apply it to programming language design is a completely different beast, with its own set of problems.