== 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) * [http://code.google.com/p/transdb/ transdb] * collumn per language for every translated proerty * [http://code.google.com/p/django-modeltranslation/ django-modeltranslation] * [http://code.google.com/p/django-transmeta/ django-transmeta] * big table holding all translations * [http://code.google.com/p/django-utils/wiki/TranslationService django-utils] * table per property holding all languages of this property * table for not internationalized properties and an extratable for the localized version * [http://code.google.com/p/django-multilingual/ django-multilingual] * language is saved as integer, which doesn't work for multiple site projects where language ids in setting can differ * [http://code.google.com/p/django-multilingual-model/ django-multilingual-model] * [http://github.com/foxbunny/django-i18n-model/ django-i18n-model] * 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) * [http://blog.rafaljonca.org/2009/03/third-style-of-django-multilingual-data.html a code example] * normal model with one language, additional table with all i18n fields in other languages * [http://code.google.com/p/django-pluggable-model-i18n/ 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 ...//... * in subdomain * as GET request (is sometimes requestet by customers) * as POST (is bad for searchengines) * language databasetable similar to contenttypes databasetable == Other resources == * Tickets: #6460 and #6952, not direct related: #9924 and #5446 * Discussions: * [http://groups.google.com/group/django-developers/browse_thread/thread/c6fdd3abea0c7f0e Thread on django-developers] * [http://groups.google.com/group/django-users/browse_frm/thread/53ec03543e9a65a1 Thread on django-users ] * [http://groups.google.com/group/django-users/browse_frm/thread/d6e7eab4cc81c7b8 An other thread on django-users ] * Blogposts: * [http://and-other-things.blogspot.com/2009/04/list-of-django-multilingual-model.html] * [http://vaig.be/2008/07/django-i18n-status.html Marc Garcia django-i18n-status] == bucket == === others === * translation over .po files, django-admin edit interface for .po files * [http://code.google.com/p/django-rosetta/ django-rosetta] * localeurl * [http://code.google.com/p/django-localeurl/ django-localeurl] [http://bitbucket.org/carljm/django-localeurl/ django-localeurl at bitbucket] * [http://github.com/nshah/django-translatable-model/ django-translatable-model] * dead project [http://code.google.com/p/i18ndynamic/ i18ndynamic]