Version 2 (modified by blubmitsahne, 9 years ago) (diff)

minor change

Use Cases

Multilingual application with no relations

Some multilangual applications don't have relations between different language versions of objects (eg. blog, each entry in one language). Here it is only interesting which language the content has, which can be solved by programmer easyly. So here no infrastructural changes are needed, but after changes this version shouldn't become slower.


  • each object is available only in one language
  • no need to share logic between representations in different languages
  • there is no representation of the object in an other language

Model implementation:

  • object per language

Multilingual application with weak relations

Some multilingual applications have weak relationships, so an object just needs to know which language it has and have a reference to objects with the other languages. (eg. wiki, see entry in other language link)


  • each object is available in at least one language
  • there is not necessary a representation in an other language
  • if there is no representation in a language, it is not a automatic fallback
  • if there is a representation in an other language, a relation should be possible

Model implementation:

  • object per language
  • link to group object, or grouping by groupid

Multilingual application with strong relations

Some multilingual applications share the logic in the object but have different localizations. (eg. customizable workflows, browsergame)


  • each object is available exactly once
  • each object has at least one but can have more than one representations in different languages
  • there is not necessary a representation in all selectable languages
  • if there is no representation in default language, there should be an automatic fallback
  • it should be possible to display the object in multiple languages on same page

Model implementation:

  • one object serves all languages (no logic duplication)

Approach overview

A brif overview of existing approaches with implementing projects.

  • propertycolumn is holding all translations (in a map)
  • table per property holding all languages of this property
  • object per language, the association between objects is provided by a goup-id (an update of the not internationalized fields would overwrite this fields in all other language objects)
  • normal model with one language, additional table with all i18n fields in other languages

Aspects and design Questions

  • setting default locale in Managers?
  • setting default locale in related objects?
  • is __unicode__(self): locals aware?
  • locale in URL
  • what if somebody needs to use internationalized objects with something complexyty adding like django-reversion, is it still possible, which limitations result form the solution?
  • getting current language easy, having easy access to other languages
  • ltr and rtl languages mixin issues if there are multiple languages used in a page as result of fallback
  • Models are often Subclassed, do the subclasses lose flexibility?
  • Mark modelfields as internationalized through attribute or through meta class (first approach is bad for subclassing)
  • fallback, you allways want/need a fallback (flexible fallback strategy? who decides how the fallback is working)

Inirect Issues, related problems

  • Language in the URI, namespaces aware of language, reverse should be language-aware
  • UI Multiforms for translations
  • oly languages officially supported by Django work or can be selected in (not sure if this is describing it exactly but there is a limitation)
  • indexable CharField could be very usefull for selection of different translations
  • language selection
    • in URL as .../<locale>/...
    • in subdomain
    • as GET request (is sometimes requestet by customers)
    • as POST (is bad for searchengines)
    • language databasetable similar to contenttypes databasetable

Other resources



Back to Top