> > Ok, had some time to look at this. Great, much appreciated!
> > 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. > You are correct, my bad. 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? Repeating "project path" at point 2 is basically me not paying attention. Sorry about that. > The translation built is constructed by: > > 1. Adding the Django translations. > 2. Updating it with the translations found in the paths listed in > settings.LOCALE_PATHS with the latter ones having greater > precedence. > 3. Updating it with the translations found in the apps listed in > settings.INSTALLED_APPS with the latter ones having greater > precedence. > 4. Updating it with the translation found in the locale/ dir under > the project dir. (this was before 3 before r12447) > > this could be described in that way or by saying that the precedence > of the literals found while building the final unified translation is > (from higher to lesser): > > * The translation found in the project locale/ dir > * the translations found in the apps listed in settings.INSTALLED_APPS > with the latter ones having higher precedence. > * The translations found in the paths listed in settings.LOCALE_PATHS > with the latter ones having higher precedence. > * The translations shipped with Django. > > See also item d below. > > 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. I'm fine either way. > > c) Regarding reversing the priority of the translations in apps listed > in INSTALLED_APPS. Comparing it with the order followed when loading > templates isn't IMHO totally correct because template lookup has a > short circuit logic while translation loading has incremental > updating semantics. 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? > > I'm not saying I'm against the change (and against the change of the > precedence of the translation is LOCALE_PATHS) the but I think we > need to discuss further to decide if they really correct and if they > are worth the potential change in translated literals in existing > projects they might introduce. 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). > > d) I think the documentation text can be changed to make it clear that > no translation searching with short circuit is done but rather a > build of a unique translation by merging in/overriding the different > parts in the order documented. Also, the note about the > LocaleMiddleware can be dropped. Will take care of this soon. > Thanks! Klaas van Schelven > Regards, > > -- > 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
