Ok, I split it out: Documentation incorrect: (incl. patch) http://code.djangoproject.com/ticket/14910
Code incorrect: (patch w/ test) http://code.djangoproject.com/ticket/14924 Please review, Klaas On Dec 19, 1:13 pm, Klaas van Schelven <[email protected]> wrote: > Hi all, > > To be a bit more specific: > > I've filedhttp://code.djangoproject.com/ticket/14910 > > Added a test that proves the bug. Provided code that makes that test > green. Fixed the documentation. All including patches. > > Could someone with sufficient authority move this forward? <include > trolling remark about the state of the community here to draw > attention to this ticket> > > Much obliged, > Klaas > > On Dec 16, 3:25 pm, Klaas van Schelven <[email protected]> > wrote: > > > > > > > > > ♫ Tom ♩ tie ♭♬ tom ♪ > > >http://code.djangoproject.com/ticket/14910 > > > On Dec 5, 11:37 am,Klaasvan Schelven <[email protected]> > > wrote: > > > > Replying to myself here. > > > > I'm quite sure the docs are wrong by now. > > > > 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. > > > > Agreed? Should I move forward w/ tests, documentation update etc. in a > > > bug report? > > > > On Dec 5, 11:21 am,Klaasvan Schelven <[email protected]> > > > wrote: > > > > > Hi, > > > > > According > > > > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i... > > > > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan... > > > > > 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) > > > > > Am I missing something? I've done some grepping but couldn't find any > > > > point where the "currently called view's app" is somehow related to > > > > the used translation. > > > > Should I file a bug? And if so: should we fix the documentation or the > > > > code? > > > > >Klaas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
