Blog
When the ubiquitous language isn't English
A talk by William Bartlett at DDD Europe 2026
Posted on 2026-11-02 - 3 minute read
Key takeaways
- "What language are we going to code in?" almost always gets the same answer: English. William argues that answer deserves more scrutiny than it usually gets.
- Coding in a language you don't fully master carries a cost: lower productivity, mental fatigue, and sometimes a feeling of being marginalised.
- Ubiquitous language is supposed to be common and shared. If domain experts don't speak English, putting it in English works against that goal.
- His rule of thumb: business terms stay in the native language, the rest of the code stays in English.
- Bilingual speakers switch between languages constantly and effortlessly. Mixed-language code, done with clear rules, can work the same way.
Why "just use English" is not as obvious as it sounds
William opened by picking the answer apart. Which English, exactly? British or American? Do you write colour with a U? Beyond dialect, there is the question of proficiency. Coding every day in a language you are not fully comfortable in is tiring. Translating a commit message into a foreign language, every time, adds up.
He also pointed out that English being dominant today does not mean it always will be. Greek, Latin, and French all had their turn as the international language of science and diplomacy.
Where this connects to Domain-Driven Design
William brought it back to Eric Evans's original definition of ubiquitous language: a common language between domain experts, users, and developers. Evans places responsibility on both sides. Domain experts should object to terms that don't fit their understanding, and developers should watch for ambiguity.
The question William asked the room: how can a language be common and ubiquitous if half the people in the room don't speak it?
A heuristic, not a rule
His suggestion is a simple table. If your business already operates in English, keep coding in English. If it doesn't, consider mixing languages, what he called Franglais, Spanglish, or Denglish, depending on the pair.
The rough split: business terms stay untranslated in the domain expert's language. Everything else, including keywords, library names, and technical conventions like get and set, stays in English.
He also flagged some sharp edges worth watching for:
- Word order. English puts the main noun last. A "race horse" is a kind of horse. Other languages reverse this.
- False friends. "Eventual" in English means it will definitely happen, just not when. In most other European languages, the equivalent word means the opposite: it might not happen at all.
- Non-Latin scripts. William was upfront that he doesn't have a good answer for mixing English keywords with Arabic or Cyrillic text, and would like to hear from anyone who has tried.
Code switching as the underlying idea
To ease the worry that mixed-language code will feel confusing, William pointed to code switching: the way most of the world's population, who are bilingual, moves between languages without translating sentence by sentence. Done with clear conventions, mixed-language code can work the same way.
Practical tips
- Document your naming conventions, for example with architecture decision records.
- If you do translate a term, keep the original alongside it in code comments or documentation, so people can search for the business term and find its English counterpart.
- Refactor gradually rather than renaming everything at once. Deprecate the old term, give people time to migrate, then remove it.
- Use resources like Wiktionary and domain-specific glossaries to find good translations, and ask domain experts to confirm.
What attendees said
I love when people speak of languages. How do we put our language in the code is really a DDD focus, but it is the first time I attended a talk that questions what the actual language of your domain language is. It is really relevant when working in France.
The speaker was very clear and presented a compelling case for his approach to the problem. It was helpful for my projects in the public sector.
Very nicely structured. Good and easy to follow.