|Version 1 (modified by blubmitsahne, 4 years ago) (diff)|
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
- 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
- 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
- one object serves all languages (no logic duplication)
A brif overview of existing approaches with implementing projects.
- propertycolumn is holding all translations (in a map)
- big table holding all translations
- table per property holding all languages of this property
- table for not internationalized properties and an extratable for the localized version
- 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
- django-pluggable-model-i18n (status: experimental)
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 settings.py (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
- Tickets: #12193, #6460 and #6952, not direct related: #9924 and #5446