The language keywords are just keywords; you simply learn their meaning. As a native English speaker, though 'while' is a somewhat intuitively-named keyword, the 'for' keyword in c/c++ has to be learned. After a while you don't notice, any more than musicians have to learn Italian to play music (quick: what do 'fortissimo' and 'da capo ala fine' mean).

I don't see any problem with source code that says something like 'auto maßtab = waage.m_maßtab();' 'auto' and '=' are simply language tokens.

> I don't see any problem with source code that says something like 'auto maßtab = waage.m_maßtab();'

There's no potential for confusion if you allow ASCII letters and 'ß'. Confusion can arise, however, when you allow all Unicode letters.

This isn't a very convincing argument to me. "We fail at source code localization in 4 other ways already" is not a good argument for "let's force a failure in a 5th way, too, even though that's the one place where there's no technical issue with it".

To me, using English keywords everywhere is a historical accident, not a design goal. In next-generation systems like Subtext [1], it looks entirely possible to add localization to source code, too.

Once you throw out the Lisp way of having one namespace for all symbols (or, OK, like 7 in CL), to be used as functions or values, and go to a system where you want to be able to statically type-check everything, why not fully commit to it and let users give local names to identifiers? Then we won't be limited to legacy C-style naming rules, or have to argue about how many space characters to add to make all their names line up on a high-resolution VT100 emulator, either.

[1]: https://en.wikipedia.org/wiki/Subtext_(programming_language)

If you work on a purely technical framework, yes it can make sense, even if i don't see why using french would be an issue for french people. Actually, i always liked the fact that since all the keywords are english, i can use mostly all the french language. When you work on a specialised field (for example some veterinarian software I worked in), learning the specific terms in your own language is already a lot. Learning how to translate those is adding much more complexity. It gets even worse when your specifications are written in one language (french in my example) and the software is written in another, so not re-using the syntax of the specifications. Add that most of the people will then have no understanding of what the code does without a list of translation, you end up in a quite messy situation...

Yes i'm saying that a lot of colleagues were lacking basic english skills, and i don't see the issue with that. English is a nice to have to communicate with people abroad, but absolutely not necessary to live in France.

It may make sense to use non-English words to name stuff that is about local legal concepts in enterprise software.

I very much agree with you. Having some strange words in the middle of a large code that is mostly english is just, well, weird. I think inconsistency is a serious issue.