I know there are some questions already here that are closely related to this subject but none of them take Ubiquitous Language as the starting point so I think that justifies this question.

For those who don't know: Ubiquitous Language is the concept of defining a (both spoken and written) language that is equally used across developers and domain experts to avoid inconsistencies and miscommunication due to translation problems and misunderstanding. You will see the same terminology show up in code, conversations between any team member, functional specs and whatnot.

So, what I was wondering about is how to deal with Ubiquitous Language in non-English domains.

Personally, I strongly favor writing programming code in English completely, including comments but ofcourse excluding constants and resources.

However, in a non-English domain, I'm forced to make a decision either to:

  1. Write code reflecting the Ubiquitous Language in the natural language of the domain.
  2. Translate the Ubiquitous Language to English and stop communicating in the natural language of the domain.
  3. Define a table that defines how the Ubiquitous Language translates to English.

Here are some of my thoughts based on these options:

1) I have a strong aversion against mixed-language code, that is coding using type/member/variable names etc. that are non-English. Most programming languages 'breathe' English to a large extent and most of the technical literature, design pattern names etc. are in English as well. Therefore, in most cases there's just no way of writing code entirely in a non-English language so you end up with mixed languages anyway.

2) This will force the domain experts to start thinking and talking in the English equivalent of the UL, something that will probably not come naturally to them and therefore hinders communication significantly.

3) In this case, the developers communicate with the domain experts in their native language while the developers communicate with each other in English and most importantly, they write code using the English translation of the UL.

I'm sure I don't want to go for the first option and I think option 3 is much better than option 2. What do you think? Am I missing other options?


Today, about year later, having dealt with this issue on a daily basis, I have to say that option 3 has worked out pretty well for me.

It wasn't as tedious as I initially feared and translating in real time while talking to the client wasn't a problem either.

I also found the following advantages to be true, based on my experience.

  • Translating the UL makes you pay more attention to defining the UL and even the domain itself, especially when you don't know how to translate a term and you have to start looking through dictionaries etc. This has even caused me to reconsider domain modeling decisions a few times.
  • It helps you make your knowledge of the English language more profound.
  • Obviously, your code is much more pleasant to look at instead of being a mind boggling obscenity.
  • 13
    +1 Extraordinary question. We do a lot of ubiquitous language development and this is a big issue for us. I look forward to good replies!
    – CesarGon
    Commented Jan 29, 2011 at 12:00
  • 2
    I think your analysis is perfect, you've thought the whole thing through. It's hard to have an answer on this subject as it strongly depends on different project scenarios. For example, if you're developing software for a law firm you might find difficult to use all words in English in your code since you're a developer and don't really know how to translate all terms. Option 1) sometimes is the answer.
    – Alex
    Commented Jan 29, 2011 at 19:37
  • I'm moving to Belgium this year to start working there and hadn't even thought of that. It'll be "interesting" to see what route they've taken, especially since I've been told some of it was outsourced (to India, I think). Commented May 25, 2018 at 21:08
  • Great question and thanks for the update - I'm also in favour of option 3 and am very happy to see some confirmation.
    – lutzh
    Commented Jul 5, 2018 at 15:21

4 Answers 4


I've faced this issue often, and in my opinion the answer is: "there is no single answer valid for all of the scenarios."

But keep in mind that Ubiquitous Language is not a goal per se. It's a tool to reinforce communication among the team and the Domain Experts and to enforce conceptual coherence of the implemented model in code, tests and conversation.

If you can speak UL unambiguously you're on the right path. If you and your peers are continuously translating from code to conversation or from concept to concept, then you're probably off track.

In practice, not all domains are equal, nor domain experts. Some domain have a lot of English terminology anyway (tech-driven domains, for example) and it sounds reasonable to opt for a full-English choice. However, some cultures might influence this choice (French comes to mind) and diffusion of English terminology varies from country to country. In some other domains (Legal, to name one) there's no way to translate some terms. Or translating would make it absolutely harder for Domain Expert to follow the conversation.

In general, we are more interested in what the Domain Expert has to say. So we want to make things easy for them. Otherwise they could just take a UML class and read our diagrams (that was a joke). So the only real recommendation here is: "pay attention to the Domain Expert behavior", if they're engaged in the conversation and the conversation goes on smoothly, you're probably on track, keep that language. It might cause a little extra work on the team, but that's fine. As developers we are somewhat trained to learn words with specific meaning in a context.

Strangely, this question always is accompanied by the assumption that all the code needs to speak one language. That might be challenged too. I am not a native English, and knowledge of a foreign language is not flat: my brain goes fast when talking about name, surname, car and the like, misses some details when talking about zipcode, slows down when talking about loan and definitely asks for a reassuring explanation when talking about mortgage.

So, again, choose the best combination that will make the key conversation flow and provide the highest amount of information and feedback from the Domain Expert.

  • 1
    Well, zipcode isn't a generic English word (that would be postcode). A ZIP code is specific to the US postal service.
    – TRiG
    Commented Apr 2, 2012 at 18:21
  • 1
    Thanks for the correction. ...this is probably one of the details that I am missing ;-)
    – ZioBrando
    Commented Apr 3, 2012 at 16:23

I recently worked on a DDD project in Switzerland, were the domain was taxes (specifically VAT and another kind of tax... that is not easily translatable to English...).

They chose the first option: UL in German, used in the code in German as well.

Before I worked on this project, I had exactly the same aversion as you for mixed language code. I (still) like to have everything in English, although I am not a native English speaker. I am also not a native German speaker. So when I started to explore the codebase, I was horrified.

After a year working on that project, I must admit that I think it was the right decision in this case (we could also have used French or Italian, the other official Swiss languages, but the majority of the actors in the project were native German speakers).

Many of the specific terms of the domain were really not translatable to English in a meaningful way. I had to learn the German terms anyway to communicate with the rest of the team. It would have been messier to have to also learn English translations, that would have been invented out of thin air anyway.

So I guess it really depends on the domain. Some domains will be really difficult to translate to English and it will not make much sense.

It probably depends on the native language as well. German is a language were you can compose words in roughly the same way and especially the same order as in English. For example a tax declaration would be a Steuerdeklaration. Not shockingly different.

I don't know how I would make an equivalent class name in French, for example, were the natural term woud be "déclaration d'impôts", with the opposite order and an extra preposition in the middle... And that is just a simple example. I would be really interested if anybody has experience with that kind of naming in latin languages (French, Spanish, Italian, Portuguese...)!

Another challenge was the plural forms, which in German are sometimes hardly distinguishable from the singular (whereas in English it almost always has an s at the end).

The accentuated characters were OK, since in German they all have a non accentuated equivalent ( ü -> ue and so on). It is another point where the French would be more problematic...

  • When you can't decide between snake case and camel case so you end up sticking all words together without using any underscores or capitalization ;-).
    – 303
    Commented Oct 29, 2021 at 19:09

I usually regard certain technical words as language neutral even if there is a translation in the other language.

For example when talking about coding in German I still use the English technical vocabulary as if they were German words even if there is a German equivalent.

In your case I'd do the opposite. Import certain technical words from your native language into English just like foreign words have been imported for centuries. Make them grammatically behave like English words. It feels strange at first, but you'll get used to it.

  • 1
    That reminds of a team of capenters I heard discussing their work. This was i Norway with some polish workers. All spoke english however most of the words related to construction and tools were in norwegian. It sounded silly but communicated well.
    – Grastveit
    Commented Aug 17, 2011 at 7:33

I agree with the Most programming languages 'breathe' English comment, that always becomes an issue with multi-language development efforts

Normally I would have the UL in the language of your programming team

What we have done in the past is to make up new words that better express the domain topics. With a French/English project the made up words where mostly English based but with french flavour (not too hard as many English words are French anyway), but this could apply to any language mix


"quantity bois"

In English is "Amount of wood" or "quantity of wood", in French is "quantité de bois", so is close enough for both speakers. This should reduce the amount of new words each speaker has to learn

How big is your domain UL? This becomes the problem. If it less than 100 key phrases then you can use a hybrid made up style language, if larger I would stick the the predominant language of the developers as they usually have to deal with it more intensely

Publish a wiki dictionary/thesaurus for everyone to reference too as required so there are no excuses for comprehension

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.