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.

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.

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.

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.