﻿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
14910	I18N locale per app resolving - documentation incorrect and bug	Klaas van Schelven	nobody	"Hi, 
According to 
http://docs.djangoproject.com/en/1.2/howto/i18n/#using-internationalization-in-your-own-projects
and 
http://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-django-discovers-translations

At runtime, Django looks for translations by following this algorithm: 
 * First, it looks for a locale directory in the application directory of the view that’s being called. If it finds a translation for the selected language, the translation will be installed. 
 * Next, it looks for a locale directory in the project directory. If it finds a translation, the translation will be installed. 
 * Finally, it checks the Django-provided base translation in django/conf/locale.

However, this has not been my experience. I also do not see anything 
in the django source code or tests that responds to the above. 
In django/utils/translation/trans_real.py I see the following: 

{{{
def translation(language): 
     [......] 
        for appname in settings.INSTALLED_APPS: 
            apppath = os.path.join(get_apppath(appname), 'locale') 
            if os.path.isdir(apppath): 
                res = _merge(apppath)
}}}

_merge (and deeper down ""merge"") is defined as a dictionary update in 
the same file. 

I see two problems here: 
 1. the documented behavior is not implemented 
 2. the implemented behavior has the opposite order-of-preference for apps as the rest of Django. (Normally, the higher up in your INSTALLED_APPS you put an app, the more likely it's templates, etc. will be called. Here we're using a dict update, so the lowest app has preference) 

Also: I think the documented behavior is not desirable. Changing 
translations per-view makes for hard to debug once-in-a-while bugs. 
This means the bug '2' is still a problem. I suggest either reversing 
the loop
{{{
158         for appname in settings.INSTALLED_APPS: 
}}}

or making the update of a 'merge' non-destructive. 

Reported before on Django-Developers, but I got no response:
http://groups.google.com/group/django-developers/browse_thread/thread/6c098e16da4c49ae"		closed	Internationalization	1.2		fixed			Ready for checkin	1	0	1	0	0	0
