id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 7163,Region locales' translation objects get overwritten,oggy,Malcolm Tredinnick,"Internal caching performed by Python's gettext module causes translation objects for different region locales of the same language (e.g. en-us and en-gb) to get overwritten. Consider the scenario of having en-us and en-gb localized versions of a project or an app. When the translation for one of these locales is first loaded, Django loads the translation objects by processing .mo files in this order:[[BR]] 1. From root django conf/locale dir[[BR]] 2. From project locale dir[[BR]] 3. From settings.LOCALE_PATHS[[BR]] 4. From apps' locale dirs[[BR]] Due to the way that Python's ugettext module works, since no en_US or en_GB subdirs are found in step 1, the base language 'en' translation in conf/locale/en will be used. Hence, both of these translations will refer to the same .mo file. However, this will cause ugettext to cache, returning two translation objects which share the '''same''' _catalog dictionary. {{{ In [15]: t1 = gettext.translation('django', '/usr/lib/python2.5/site-packages/django/conf/locale/', ['en_US']) In [16]: t2 = gettext.translation('django', '/usr/lib/python2.5/site-packages/django/conf/locale/', ['en_GB']) In [17]: id(t1._catalog) Out[17]: 3079088844L In [18]: id(t2._catalog) Out[18]: 3079088844L }}} Therefore, any changes to one translation at stages 2-4 will effectively change the other one as well, rendering regional translations useless at the project/LOCALE_DIRS/app level. To prevent this, it's necessary to perform a deep copy of the translation object at stage 1. Since Django implements its own caching of translation objects, this should not affect the performance too much.",,closed,Internationalization,dev,,fixed,translation gettext region locale,ognjen.maric@…,Accepted,1,0,0,1,0,0