Closed Bug 532016 Opened 14 years ago Closed 14 years ago
Move locale checkbox to footer and create an admin level pref so we can set the default checked status for each locale
As discussed, we should enable this filter via the footer. It should affect any listings that aren't editorially selected (i.e. everything but the collections module and recommended add-ons).
This affects L10n, searches, and several listings. That's a big change to take this far past code freeze. Kicking to 5.5, let me know if you want to talk about it.
Target Milestone: 5.4 → 5.5
So this is involved, but my plan is this: the checkbox, will set a preference which we'll store in the users table (thinking a generic preferences field, since we'll likely have more preferences in the future) and search/browse can evaluate this preference fairly quickly. In v.4 we can store these prefs in memcache.
The goal of this patch is to do the following: * have a checkbox at the bottom of each page if a user would like to elect to see addons only in their locale * for a setting in the admin localizer tools that allows an admin to specify whether certain locales are xenophobic by default (e.g. ja should be) * and lastly we take into account this setting and filter results accordingly - this is done at a fairly low-level just before we talk to the Sphinx API. Note: * We add a checkXenophobia function as part of our beforeFilter * checkXenophobia takes care of all the cookie settings, settings via get request, default settings, etc. * we completely remove the checkbox settings that were just on the browse page in favor of our new global checkbox
Attachment #419995 - Flags: review?(clouserw)
Comment on attachment 419995 [details] [diff] [review] v1 - If I check the box from a search results page it loses my search. This happens with the locale switcher too so not a blocker but jarring. - sometimes you're doing 4 space indenting (first level of checkXenophobia()) and sometimes you do two. All our PHP should be 4. - it's an edge case but I'd like to see some assuarance that $_POST['locale'] is in valid_languages before redirecting the user in xenophobia() - just an observation, but this may encourage authors to fill additional locales with English since that will cause their add-on to show up in more searches.
Attachment #419995 - Flags: review?(clouserw) → review+
Also, perhaps better wording for "Show only Русский addons for ru by default" would be "By default, only show add-ons with translations for this locale. This affects all searches, listings, and browse pages for all users." I'd like to somehow say that we're only talking about metadata and not actual translated add-ons but I don't know how to squeeze that in there. Maybe stephend has ideas.
Not sure why this is still open; this code has landed. QA: In addition to the testing here we're also doing something we've never done before with Zeus so please make sure this setting works as expected both logged in and out. Details: We've asked zeus to read the locale-only cookie we set and serve the appropriate page from it's cache. Effectively this creates a Vary header based on a single cookie instead of the entire Cookie header.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
test case: - check a search page, logged out with no locale-only cookie. Is the page cached and does it have appropriate content? - check same page, logged out with locale-only cookie set to 1. cached and right content? - same page, logged out with locale-only cookie set to 0. cached and right content? Log in, repeat tests. Pages should not be cached and should have right content.
Krupa and I ran through comment 7 on both Windows and Mac, separately, and all is well; she also verified the site-wide Admin preference using zh-TW.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.