I'm requesting best practice with this question. This is only an issue if the customer company is strictly national has a native language other than English, I think.

If the customer has a lot of mainly very domain specific (say, German) expressions, mixed with some lesser domain specific namings. The language of our code comments, class/method/variable names is English. Would you translate all domain specific names?

  • 12
    English. Lingua franca for programming.
    – Rig
    Commented Aug 17, 2012 at 15:20
  • 6
    One of the more 'challenging' PHP error messages has an interesting Hebrew twist: unexpected T_PAAMAYIM_NEKUDOTAYIM. Having seen this a few times in my life, I have no doubts that one should use English.
    – K.Steff
    Commented Aug 17, 2012 at 17:47
  • 3
    Do any of the German domain-specific expressions have non-standard characters (say, umulauts (sp?))? If you hire programmers outside your region, they may not be able to find a keyboard with the requisite characters (mine doesn't). Yes, there are ways to switch the 'typed' language, but I wouldn't want that hassle. Commented Aug 17, 2012 at 18:13
  • 2
    Greek -- using non-latin alphabets is better job security than klingon. Commented Aug 17, 2012 at 22:19
  • 3
    @X-Zero going outside plain ASCII opens the "what character encoding do we use" can of worms. Usually you get bitten and don't go there again.
    – user1249
    Commented Aug 18, 2012 at 13:36

6 Answers 6


I'm working in Germany and I prefer to pick English.

Sometimes e.g. domain specific things like creating an module to "DATEV" (german invoice/billing software) I do use German names. Some German words cannot be translated properly, e.g. "Referenzbuchungsnummer" (ReferenceBookingNum?) or "Sachkontenlaenge" (..?). Also I do think that domain specific things would be ending in maintenance horror. Maybe you would remember that ReferenceBookingNum would relate to "Referenzbuchungsnummer", but what about your co-workers? They have to study internal documentation about naming, if documentation exists. They won't be very familiar with the module without having proper names. It's an unnecessary complexity if all other developer are German too. But "CakeFactory" sounds much better than "KeksFabrik" ;)

So it all depends.

  • 2
    This answer reflects my personal oppinion the most, after reading the other answers. Especially this point: "It's an unnecessary complexity if all other developer are German too" when translating everything.
    – Zeemee
    Commented Aug 20, 2012 at 7:00
  • 1
    @Mulmoth: "It's an unnecessary complexity if all other developer are German too" --- How can you be sure that at a point in time, in some years, the project won't be outsourced to another country? How can you be sure that a non-German speaking developer won't be introduced in the project at some point in time?
    – Coral Doe
    Commented Aug 20, 2012 at 7:26
  • 5
    @Coral Doe - I think that new/other/outsource developer already have to dig deep into the business domain and its specific expressions. So imho it is easier to map what the customer (which will still be german then) sais to german named classes istead of badly/wrongly translated english names.
    – Zeemee
    Commented Aug 20, 2012 at 7:35
  • 2
    German billing/tax related "stuff" will never be outsourced to a non german speaking country. At university someone told me that 85 percent of all billing/tax books refer to german laws and are written in german. worldwide. Commented Aug 20, 2012 at 8:23
  • 3
    I agree but one problem that almost always happens is that the language used by developers leaks out to users and other stakeholders. Not as part of the ui but how you speak about the problem domain. This will inevitably lead to confusion as not everyone is as fluent in english as most developers are. Commented Aug 22, 2012 at 5:32

Being Norwegian working in a Norwegian company I name my objects in English. Of course some words or concepts might not have a English counterpart and in that case one can argue that a native word might be used in place of a bad replacement or literal translation which has not meaning. Of course, much of these problems might be the fact that some of us should have a better vocabulary so I usually ask a colleague if I can't think of a good English name :)

Some of our staff are not Norwegian and thus writing in English benefits them. Being able to hire programmers from most of Europe is good for the economy so my company benefits from it too.

BTW: I remember I read the source of Hermes once (ebXML b2b implementation) and I would have had a hard time if they would have written and commented in Mandarin.

  • 5
    Almost edited "college" to what I assume is supposed to be "colleague" but I was not sure if it was intentional. Commented Aug 17, 2012 at 17:54
  • Of course I meant colleague :)
    – Sylwester
    Commented Aug 18, 2012 at 12:59
  • Of course some words or concepts might not have a English counterpart - I am always curious when that comes up in programming, almost like you might know a design pattern that English-only speakers wouldn't come up with. Do you have a quick example?
    – Izkata
    Commented Aug 19, 2012 at 5:34
  • 5
    @Izkata: the question was about business classes. They're more often tied to country-specific rules and regulations. E.g. if the law forces you to track the location of all trucks with dangerous chemicals, you might very well name that class after that law.
    – MSalters
    Commented Aug 19, 2012 at 20:50

I believe that since English is the lingua franca of the IT domain, limiting your source code to another language creates artificial obstacles to it's development. First you limit the pool of the people that can contribute to ones that speak a specific language. The same reason that you asked in stack exchange and not on a local site.

Also you do not know where contributions will come from and where will go to. What if you use a sample from a site, will you translate that? What if the product expands to be used from clients in another country? Case you need to hire a contractor/ outsource a bit? Why limit to one pool and not get the most fit from all over the world?

Can assume that it is OK for some domain specific structures that do not map easily to other languages, or if an existing code base is maintained.


My last project goal was to model business domain of collaterals and mortgages. All the developers and the company we worked for are from Poland. We built the software following Domain Driven Design principles. We used Polish names for all the business entities and I think it was a very good choice. I think that we were able to avoid communication problems thanks to this approach. Business domain consisted of many terms that I didn't even know in Polish, not to mention English translations. We used only latin letters and all technical classes were named in English.

  • 4
    That's a good point: if all domain knowledge is in the local language and no agreed-upon English names for the domain concepts exist, using the local language can be a good idea. Commented Aug 20, 2012 at 6:27

It is generally easier to read source code written in a single language. This for most programming languages implies you should write it in English.

That said, there is a major problem with domain concepts which do not easily translate into English. A typical example is a unique identifier which the society gives the individual - in the USA the closest concept is the social security number, but it is not an accurate mapping. Names and telephone numbers usually map quite well.

I believe that it is usually necessary to keep the domain terms whenever an accurate mapping is not readily available into English, but only those - keep the rest in English. It will result in unusual identifiers like KommuneImpl but it should make immediate sense to those who know the domain.


Open-source / international community type projects

The common language of open-source and international community projects is English. Case in point, the language of the Stack Exchange sites is English. For broadest accessibility, English should be used for all code and object names.

Commercial Projects

Most international software firms mandate code to be written in English. It's the greatest common denominator, so it makes sense to use English as a means to create consistency.

Many regional software firms write in their native language. Not all follow this approach, but it makes sense from their point of view - they use the common language for all of their developers.

Naming business objects

The coding language of the team should be used to name objects.
The priority is for the developers to be able to communicate with each other regarding the objects and the project requirements. If the team writes in French, then the business objects should be named in French. If they code in English, then name the objects in English.

Your question adds a wrinkle because the client speaks a native language other than your team's coding language. You should still use your team's coding language to name the objects.
When the business analysts or developers need to communicate with the client about the specific business objects, an as-needed translation of the object name from the coding-language to the client language may be required. From my experience, it's pretty rare that I've talked about specific code objects with the client so the translation back to the client language hasn't really been needed.

The only exception to the naming rule is when an object has no other sufficiently concise term to capture the intent of the object. IMO, this is really rare, but it can occur. In reality though, it's the same thing spoken languages do to express particular concepts. "Facade" is originally a French term but has been adapted by English in order to express the concept, and is a common design pattern. "Schadenfreude" is another good example of a borrowed term although I don't think it has a corresponding pattern.

  • 1
    Your final paragraph totally contradicts your first one, it seems
    – James
    Commented Aug 17, 2012 at 19:18
  • @James - thanks! I removed that section since I don't have the time at the moment to clarify what I meant. It was supposed to be supporting, but no matter.
    – user53019
    Commented Aug 17, 2012 at 19:43
  • 1
    Strongly disagree. Since the core concepts of practically every language you'll meet are written in English, using non-English terminology leads to less legible sourcecode. The mind constantly has to jump between English and the other language. Code should be fluent and readable.
    – Mike Adler
    Commented Aug 18, 2012 at 6:20
  • @MikeAdler - it's not clear if you disagree with what I suggest as the general rule (name things in the team's language) or the exception case which should be very rare.
    – user53019
    Commented Aug 18, 2012 at 13:20
  • Granted. I'll clarify: I disagree that any object should ever be named in a language other than English. Your first heading 'Open Source / international community type projects' reflects my point of view very well. Everything after that, I'm not buying. The reason, as stated, is maintainability, which should be an overriding concern for practically every design decision (including naming scheme) you make, in my opinion.
    – Mike Adler
    Commented Aug 20, 2012 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.