[Jtsummers]

https://en.wikipedia.org/wiki/ALGOL_68#Example_of_different_...

Algol 68 offered that, for keywords at least. Variables, procedure names, and the contents of strings can't be localized quite the same way (though localization for content is easier now than it used to be if you don't embed the string text directly in the source).

If we switched from a text file based representation of code to a different structure, localization could be performed more easily for source code even down to comments and variables. However, this would help you to work on a project I started, taken too far it would not help us work together (we'd refer to the same variables and procedures with different names). We'd still need to select a common language when collaborating.

Other languages, today, at least work well with unicode source but they retain English-based keywords (Go, Rust, probably others but they like to tout it specifically).

[jayathra]

Localizing everything could make collaboration harder if different people refer to the same function by different names.

But what if we had a system where people wrote code in their native script, and it automatically translated into a universal format when shared? Would that help keep things accessible while maintaining collaboration?

[Jtsummers]

That's what I suggested, but it means our person-to-person collaboration becomes more challenging, though if we work at arms length with each other it might be more feasible. You always work in your translated code, I always work in mine. But direct communication about code breaks down because we need to have a translator and decide on the common terms.

We could probably collaborate at a higher level (system architecture and design). I'm building a compiler, I can share the architecture with you and have you implement a particular optimization pass. But if I want to read your optimization pass code and discuss it with you then one of us has to learn the same code twice: once in our native language and once in whatever is decided to be the shared language.

Store the code in a database (or something akin to one) and use a structured editor and this mode is technically feasible. It would open up work for people who are not native in the original language, but you also need to ensure that code has a translation. So you're still going to need someone (or something) to do the localization as well.

OSS projects can't afford this, but commercial efforts might be able to. On the other hand, commercial projects can afford to be the $2/hour extra (companies are cheap bastards) to hire those English speakers in your country and ignore the non-English speakers.