And it makes support, reusable code, common understanding, and readability (in a team) fly out the window, and increases the amount of development overhead of whomever has to maintain the language.
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?
> You don't write new code when you i18n something, you just create dictionaries.
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.
> 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.
I argue that i18n is not translation.
It seems like you're making a point for solving problems beyond the scope of PL internationalization, including problems that are not solved when it comes to how english code translates to english natural language.
My original point is that foreign excel versions already did help people. From there, improving compilers to make that work easier and less costly is a reasonable goal, or at least a tractable one. Some of that work is already being done for unrelated reasons (e.g. modern compilers offer interfaces for LSPs as well as error messages in formats that allow processing beyond reading for CIs — both of these changes benefit potential i18n efforts).
Only if the said support and code are not localized too. I'm using all my devices in English because it's easier to find help online but I can see why people less proficient in it would prefer localized software down to formulae and documentation.
