On Thu, Jan 13, 2011 at 4:13 PM, Klaas van Schelven <[email protected]> wrote: >> >> a) The doc fix attached to #14910 to describe the current situation >> and that got committed isn't correct. At no point of the catalog building >> process a '``locale`` directory in the directory containing your settings >> file.' is involved at all. And it doesn't mention the LOCALE_PATHS part. >> > > [...] > > What I meant with "a ``locale`` directory in the directory containing > your settings file." is "the project path". It is/was not clear to me > that Django thinks of the location of the file you specify when doing > --settings=some_settings as the "project path". This may lead to > unexpected behavior when you put your actual settings file in a > different location than the rest of your project files. Which led to > unexpected behavior for me. > Is this conflation of "the path to your specified settings file" with > "project path" the default Django behavior? I can imagine there's > other cases where a notion of a project path is used. If so: is this > documented somewhere? >
For me the project has always been the place where the settings file is located. And yes, grep shows there are other places in Django that makes this assumption but based in the structure created by startproject; the project and application distinction and definitions are touched in part one of the tutorial. I agree with that we can be a bit more specific here and will refine that paragraph when updating the docs. Thanks for the heads up. >> b) I'm not sure I understand what converting the merge to a no >> destructive update has to do with all this, I think the behavior of a >> dictionary update() on the catalog being built is basic for the >> translations overriding functionality. > > If we decide the he fact that the later latter elements in the lists > (INSTALLED_APPS and LOCALE_PATHS) have higher precedence is non- > intuitive, we can implement a reversal of that order in one of two > obvious ways: > 1] make the update non-destructive, and reverse the order you mention > above (1-4). > 2] wrap both of the lists with reversed(), or something to that > effect. Ok > > I'm not sure what you mean by "short circuit logic" and it seems to be > a key part of your argument. Could you explain? > By short circuit logic I mean thay in the case of templates, one template is looked up by traversing the paths in the documented order and when one is found the lookup ends there. > > On the matter of backwards compatibility I can only make an educated > guess and express the hope that others will chime in on the issue. > > I have one clue that this will not lead to many backwards > compatibility issues. Which is: I haven't found anyone else > complaining or asking about the issue on Trac or elsewhere on the > internet. > > Having said that, I think the proposed changes are "the right thing", > because: > > 1] on the matter of the reversed order within the lists > (INSTALLED_APPS and LOCALE_PATHS) this is the exact opposite of > Django's templating behavior, and for example the way staticfiles > works. So the behavior is unexpected, and will therefore lead to bugs. > Secondly, this means that if you have an application that depends on > the order of the apps for both templates and localizations, you're > hosed, because you can't put A before B and B before A at the same > time. > > 2] As to the higher preference for LOCALE_PATHS, I'll just repeat that > the reason someone would put up a specific path for locales pretty > much has to be to override the existing behavior (which would be found > in project and apps). > I'm leaning to agree in general with you regarding the directory precedence order schema. But I'm still unsure we will be able to do this before 1.3. I will attach a patch to the ticket and ask for opinions. Thanks, -- Ramiro Morales -- 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.
