Skip to content

Locale priorization for translations (bug 983749)#18

Closed
magopian wants to merge 8 commits intomozilla:masterfrom
magopian:983749-locale-priorization-for-translations
Closed

Locale priorization for translations (bug 983749)#18
magopian wants to merge 8 commits intomozilla:masterfrom
magopian:983749-locale-priorization-for-translations

Conversation

@magopian
Copy link
Copy Markdown
Contributor

fix bug 983749

The aim of this PR is to have various fallbacks when requesting a translation,
and not only one as we have at the moment.

Before: first get the translation for the active language, and if there's none,
check if there's a fallback translation (either in a locale provided via
model.get_fallback(), or the settings.LANGUAGE_CODE).

After: Check the following locales in order
1/ the active language
2/ the model fallback provided by the get_fallback() method (if it exists)
3/ settings.LANGUAGE_CODE
4/ in last resort return just any translation found

This PR is quite hairy, as I implemented it in a way to minimize the number of
joins: if the three locales to choose from are all the same, just join twice
(once for the locale, and once for the "last chance" fallback returning any
translation) instead of four times.

I've tried to factorize as much code possible between translation.query
and translation.transformer.build_query, but both are using different
APIs, and for different use cases, so the only bit in common is the
get_locales function.

I've tried to comment it as thoroughly as possible to ease the review and the
maintenance, but I aknowledge that it's still a big piece of SQL generation,
and deep django code.
If you need help understand some pieces of the code, please let me know and
I'll try my best to explain it.

Comment thread apps/translations/query.py Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put the comment on a new line to be consistent with Second/Third ones.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mention somewhere in the docstring and/or the inline comments that it tries to avoid duplicates.

Using .distinct() is too restrictive on the queryset and prevents it to
be used in more general ways. Another solution is this hack to add a
group_by clause.
@magopian
Copy link
Copy Markdown
Contributor Author

This PR can't be merged as is, as it's introducing a "group by" clause (magopian@c792776#diff-547abaa7344efed8cabde90545e60135R132) that is very bad performance wise.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This group_by, at this place, is very dangerous: it will merge two addons with the same name. If a "group by" must be done, it may perhaps be done at the JOIN level using something like:

JOIN (
    SELECT * from translations
    WHERE localized_string IS NOT NULL
    GROUP BY id
) T1
ON xxxx.name = T1.id

@magopian
Copy link
Copy Markdown
Contributor Author

magopian commented May 5, 2014

Closing this for now.

@magopian magopian closed this May 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants