Let's say I have a Book that has it's title and description localized in any number of languages.

Localization only matters for e.g. administrators, because users chooses their localization and they need to see only their localization, not all of them. Administrators, however, needs to have full support for localization management.

I would have two entities for this: Book - that is localized for the user. The repository would be aware of localization, so we don't even need to pass current localization all the time.

Then, I will have another entity: Book2 (yeah, needs a better name) that will contain a Map<Locale, String> instead of simple string for a title. This entity would be use in 'admin' context.

I also do not see a way to make both Books to be of the same type.

Would this be a good approach? Any wisdom on this?

  • What toolset do you use to describe your domain model? Are you free in choosing the datatypes of your attributes, or can you extend the list freely? If the latter is the case, why not add a new datatype "LocalizableString" to your toolset? – Doc Brown Nov 12 '14 at 18:19
  • I was thinking about that - LocalizableString would be composition of current value and explained Map, right? So I would carry around all translations? – lawpert Nov 12 '14 at 20:21
  • 1
    On the abstraction level of your implementation, this will be a possible solution. On the abstraction level of the domain model as an Ubiquitous Language, it is just a placeholder for a localizable string. For your stakeholders (like users or administrators) it should not matter how the model will be implemented in detail. If this is possible depends on the levels of abstractions your toolset provides. – Doc Brown Nov 12 '14 at 20:36
  • Ok, I just wonder if 'LocalizableString` should be used in both cases (for viewing and for admin). If this is one type, then localization feature is leaking into the users world. And from the user side, they should not care if book name is translated to any other language. Therefore I wonder if this concept should be hidden from common users and only visible to the admins - hence the two model classes? – lawpert Nov 13 '14 at 11:44
  • DDD emphasizes on the concept of having "one language for all members of the team" - I would try to stick to that approach as long as it does not hurt too much. And if your users are not total nuts, I guess they will understand the fact that the domain model will have to reflect not only their requirements, but also the requirements of other stakeholders. – Doc Brown Nov 13 '14 at 12:29

I have used a complex properties for this kind of situation, with the following structure:


The Value inside TranslatedValue is filled with value for the current user's locale. The TranslationList contains all of the transaltions for the locales.

This way, you can easily control which values you want to load, and simple access both current locale and other locales:

MyBook.Title.Value // Gives the value for the current locale
MyBook.Title.Translations["french"].Value // Gives the value for the french locale

Hope that this idea helps you.

| improve this answer | |
  • Nice! One question: you are loading all translations. Do you find this as an overkill (memory usage)? Because we have translation to over 20 languages already :) – lawpert Nov 12 '14 at 20:18
  • In majority of cases, I only load Value for the current locale. Load other translations only when you need them in special cases. – Dusan Nov 12 '14 at 21:12
  • But this leaves our Model object 'half-initialized'? I would like to prevent that - imagine many models and many developers working on this, and number of NullPointerExceptions in runtime :) Hence my question, where I want to prevent such cases, and make developers sure what they are using. – lawpert Nov 13 '14 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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