Version 2 (modified by 15 years ago) ( diff ) | ,
---|
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.
Specialities:
- 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)
Specialities:
- 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)
Specialities:
- 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)
- collumn per language for every translated proerty
- 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
- django-multilingual
- language is saved as integer, which doesn't work for multiple site projects where language ids in setting can differ
- django-multilingual-model
- django-i18n-model
- django-multilingual
- 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
Other resources
bucket
others
- translation over .po files, django-admin edit interface for .po files
- localeurl
- django-translatable-model
- dead project i18ndynamic