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?

UPDATE

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.