Most programming code, I imagine is written in English. But I'm curious how people are handling the issue of naming herein. A lot of programming is done within some bussiness domain, usually with well established terms for certain procedures, items.
I'm from Denmark for instance, and something I work a lot with has a term called "indblikskode", which sort of translates to "insight code". So, do I use the line "string indblikskode = ..." in the C# code for some web service related to this? Or do I try to use a translation, such as "insightcode"? The bussiness I'm in isn't even consistent in its language, for instance using the term "organisatorisk enhed" (organizatorical unit), but just as often using the abbreviation "OU", which is obviously abbreviated from the English.
How do other people handle this naming issue, while keeping consistent, and sane (in everything from simple variable names in your code, to database tables, to server names)?
Duplicates:
See my question and answer here.
Basically it depends on your organization and the application. If your company, developers and customers all speak the same native language and you expect it to stay that way, then it would be extremely counter-productive to have everyone become a part-time translator as well. Considerable productivity loss for a purely hypothetical future advantage. YAGNI.
If it's a large international company, or if there are concrete plans to expand internationally or have some work done offshore, it's a different matter, of course.
I can only speak for myself, but I always translate terms into English when naming classes and variables, and it's one of our unwritten best coding practices to do so as well. You never know when you might need to hand off development to cheaper labour abroad or the expert expat consultant in town.
The problem with non-English naming of classes and functions is, that you invariably going to end up with macaronic pidgin. Keywords are in English, naming conventions (like for example getters/setters) are also English, same for standard names for design patterns.
You're going to end up with stuff like:
OrganisatoriskEnhedFactory::getInstance()->getIndblikskode();
Having worked in Switzerland (German side ie Zurich) and lived in Germany for a time I can tell you that I've yet to see an environment where the code isn't in English. Sure the application may well be in German (but many professional environemtns are English-speaking anyway) but the code (I've seen) is pretty much all English.
It's hard to write code in other languages. For one thing, the APIs are (nearly) all in English. Java uses JavaBeans naming for example so you have to use set and get anyway and "getGeburtstag" just doesn't have quite the same ring to it as "getDateOfBirth".
Other countries may vary for this has been my experience from the Germanic countries.
We're usually using established English terms (our business domain usually has English terms), but if I can't figure out any suitable term, I could as well use Finnish. Heck, even our comments in code are in mixed languages...
Of course the sensible approach depends largely on whether the source code will ever be used outside the building. In a small shop it's not such a big deal.
I'm working in a company in Austria (so we're talking German) and we are programming in English (variable names, domain objects, GUIs). Makes it a bit more cumbersome, because you have to find the English translations and you have to translate the GUI before releasing the program. I'm not really sure if all the names are really correct.
In contrast in the former company I was working for programmed strictly in German. This was pretty nice (altough German words tend to be longer than English words). After some years the company wanted to use the same program in the USA, so English-speaking programers had to use the same codebase. after this everything got pretty inconsistent- variables, database fields.. in both languages (the English speaking team members didn't talk German).
My experience is that it is easier to handle internationalization in the early beginning (you are forced to do it when you write the program in English) of an application, because it is no big fun localizing a 10000 LOC application. The advantage of writing in another language is that you see instantly what is localized and what is not - altough it's work you have to take in account for that.
To the untranslatable words: we hadn't expierienced that yet - altough it was some work finding the English phrase for "intra-community deliveries" (that's an EU thing). But if that would happen I'm pretty sure we would use the German word.
I live and work in Germany but write English code only. It makes things easier. You can post your code on the net if you want to ask questions or want to publish tutorials about your work.
Also the code looks more "professional" for me.
I also live in and work in Germany for now and we mostly use English except for some old comments in German. I think non-English comments are generally very bad idea since you'll have to spend time trying to understand it (and understand correctly). Although both German and English are not my native languages, code written in anything other than English seems to be bizarre.
You'll never know who would be working on your code the next day. So you should use the universal IT language.
P.S. Since I do not like non-English languages in my development environment, I made a local administrator quite angry when I refused that my PC be installed with German Windows, German Office and German Visual Studio. It took many hours to download the English versions just for me.
Though I think it is good one day to install a language pack or just a different copy of the same software just to learn the terminology. SQL Management Studio in French makes me really excited, just as when I tried to switch Skype to Spanish.
来源：https://stackoverflow.com/questions/685468/non-english-domain-naming-issues-in-programming