On Thu, Dec 23, 2010 at 7:43 AM, Klaas van Schelven
<klaasvan...@gmail.com> wrote:
> Hi all,
>
> Thanks for checking in 14910!
>
> Could anyone take a serious look at
> http://code.djangoproject.com/ticket/14924
>
> It has a test that proves the problem and a relatively simple patch.
>
> I'm doing a lot of "app overriding" and this bug is extremely annoying
> in that case. It would be great if the fix could still make it to 1.3
>
I'm pretty sure a design decision will be made about it before 1.3 gets
released. It is in the list of tickets I want to look at, and I know it is in
the radar of at least one core developer.
Just bear with us, we have a lot of tickets (some of them older
and/or uglier) to review and fix and one almost seven weeks to work on
bug killing before 1.3 goes gold.
Thanks for reporting, following and contributing to the solution of
this old issue, and for your patience.
--
Ramiro Morales
>
> Input (discussion) on this is much appreciated. I'll gladly put in a
> new patch once a decision is reached. If this is a separate issue, I'm
> also fine on opening a separate ticket. (it could be argued that we
> can move forward on the original bug report as a separate issue more
> easily, since it's "obviously broken")
>
Ok, had some time to look at this. These are the notes resulting from that:
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.
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.
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 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.
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.
Regards,
--
Ramiro Morales
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