What about a format for code localization for code repos? A bit like a `.pot` file for string translation, but instead it applies to names.
For reading code in another language, you apply the .pot file to the code base in a separate branch and it does search and replace in the source files so you have the same code base localized (assuming utf-8 everything).
When running code with localized identifiers, any single word, underscore_connected, and CamelCase identifier is "looked up" and "symlinked" to the correct identifier in the default locale (English). Think "search and replace" at the AST level of the language.
I'm not completely sure how well that would work in practice, as many times programmers don't use actual works for names, but abbreviations (len, dict, etc.). That being said, I think the example the author gave about Excel worked well because there was an already-enumerated set of functions that needed to be localized. I could totally see it being feasible, if tricky with regards to parsing, for (programming) langues to provide a compiler/interpreter flag to instead use a different translation/localization for keywords and standard library identifers, which although presumably more numerous than the number of functions in Excel, are still an already-enumerated set. Given how most languages rely on community contributions for translating documentation, they could presumably ask the same contributors to help with localization of a language's built-in and standard library identifers.
The topic of learning to program as a non-english speaker has come up a few times with friends and coworkers, despite all of us being native english speakers.
I've proposed that languages like Golang and Swift that support unicode should go a step further, and come with a translation file for their keywords, which is then fed into the lexer/parser.
It doesn't solve the problem of an international codebase, or let you switch languages as shown in the Excel example, but it would at least make it significantly easier to learn and write code in one's native tongue.
And it could be available today, without significant changes in tooling on either the compiler vendor's side (except the translation tooling of course) or the developer's side.
Translating the tens of keywords in a given typical language won't get you very far though - you need translations for all the terms in all the commonly used libraries, and documentation of how to use them.
That is true, bare minimum you'd need to translate the stdlib, and at that point you're translating identifiers, which means you might as well go for translating everything as shown in the Excel example.
For reading code in another language, you apply the .pot file to the code base in a separate branch and it does search and replace in the source files so you have the same code base localized (assuming utf-8 everything).
When running code with localized identifiers, any single word, underscore_connected, and CamelCase identifier is "looked up" and "symlinked" to the correct identifier in the default locale (English). Think "search and replace" at the AST level of the language.