[pyrale]

> Go switch Excel or Google Sheets into a language you don't know.

I don't believe that point supports your claim. Switching excel to a language you don't know is a good example of the benefits people who don't speak english get from localized languages, not the other way around.

> Come back and tell me if localized programming languages are a good thing after that. :D

The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business.

Likewise, localizable languages for children (e.g. Hedi) work pretty well at helping children discover computers before they have a firm grasp of english.

[junon]

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.

[pyrale]

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

[junon]

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

[pyrale]

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

[TeeMassive]

> orthogonal concern

Sorry to be blunt, but you have no idea of what you are talking about.

[tasogare]

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.

[TeeMassive]

> The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business.

I got paid a lot to transform projects that used abusively Excel sheets. All of them had absurdly long delay and cost explosions caused by this.

Excel sheets are for small business and small projects by non-programmers. Excel sheets in a non-English language are for small businesses and small projects by non-programmers that are doomed to stay this way. This is because having programmers that want to unfuck a mess of macro AND speaking your foreign language simply are very rare AND doing so before the business implodes are very slim.

[pyrale]

> I got paid a lot to transform projects that used abusively Excel sheets.

I wonder where all this money came from.

I also got paid a lot to transform projects that abused excel, among other things. The usual truth was that, without excel (or, on other projects, without their tortured python scripts, or without the off-the-shelf software modded to death), these companies would never have built a business successful enough to pay entire teams for months or years before any returns.

> having programmers that want to unfuck a mess of macro AND speaking your foreign language

I mean, at which point did the idea "Oh, that language is so weird that very few can possibly speak it _and_ learn to program" start to make sense to you?

Did it ever occur to you that my foreign language was the first language of a whole lot of people living in my country, and that maybe there are a few good universities here?