Closed Bug 892696 Opened 12 years ago Closed 12 years ago

new bedrock /newsletter page + l10n

Categories

(www.mozilla.org :: Newsletters, defect)

Product:
www.mozilla.org
Component:
Newsletters
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jdavis, Assigned: pmac)

References

Details

(Whiteboard: r=118191)

Heyo! On: https://www.allizom.org/en-US/newsletter/ If you try to go to a different newsletter locale (ie fr) the page redirects to en-US. We need either: 1) Put in code to redirect to php version of l10n site or 2) Get this page localized and up before it goes live. We have to have l10n versions of this site available at all times.
We're working on a test for this, right now: https://github.com/mozilla/mcom-tests/issues/211
OS: Mac OS X → All
Hardware: x86 → All
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/ce879c6983cf5baaf28f386d55bbe0f0c1167ad6 [Fix Bug 892696] Use bedrock newsletter page for en-US only https://github.com/mozilla/bedrock/commit/7b0f5c08bb28ab099756124568bb0ecd6923f44f Merge pull request #1055 from Sancus/master [Fix Bug 892696] Use bedrock newsletter page for en-US only
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
All the translations exist already, we made sure not to change any strings. We just have to add the ## active ## tags to the lang files.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The following locales appear to be the ones that are active oh the PHP side: csb, de, en-GB, en-US, es-ES, fr, hu, id, pl, pt-BR, ru This seems like a good place to start for enabling in bedrock. If there are no objections I'll activate the lang files for these and submit a PR to enable the bedrock version of the /newsletter page for all locales. This will mean that the above locales will appear translated correction, and others will redirect to en-US.
Whiteboard: r=117989
FWIW - en-GB on the php side has been broken for awhile: Bug 829194 Will enabling this locale on bedrock keep the form broken? Or automagically make it work? I'm cool with taking en-GB out of the list of locales for this page and just having en-US if that's easiest.
Whiteboard: r=117989 → r=117989,118007
Lang file activations are on prod in r.......... This still leaves the question of which locales we want to eventually activate. Pascal pointed out on IRC earlier that the strings are fully translated in 42 locales: http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=newsletter.lang Even though the newsletter isn't available in most of those, it still seems like a good idea to show the page in the user's language, and then allow them to chose the language (if any) in which they'd like to receive the newsletter. Otherwise everyone else gets the english page, which they may not understand.
That prod in r118010 and r118013.
Now all that remains to get these locales live on bedrock prod is to update the apache config to forward all locales to bedrock instead of just en-US as it is now. PR for that is coming shortly.
PR opened. Ready to merge at any time and then /newsletter/ will be live for all activated locales, and all others will redirect to en-US. https://github.com/mozilla/bedrock/pull/1062
Depends on: 893162
Depends on: 893165
+1 with the blocker that the default language should be blank so that they must manually choose the language. This way we don't have people flying through the signup process and don't realize that they chose a language that shows by default. Should this new feature (have a blank language that then must be selected) be a separate bug?
Blocks: 829194
(In reply to Jessilyn Davis from comment #10) > +1 with the blocker that the default language should be blank so that they > must manually choose the language. This way we don't have people flying > through the signup process and don't realize that they chose a language that > shows by default. > > Should this new feature (have a blank language that then must be selected) > be a separate bug? It sounds like we want to take out all the code that tries to pick a good default based on the current locale, when we don't know the user's preference already? If so, let's make it a new bug.
(In reply to Dan Poirier [:dpoirier] from comment #11) I don't think it sounds like that at all. I believe we should pick a good default if they're using a locale supported by the newsletter. If we can't pick a good default we shouldn't have a default and the filed should be required.
I'm confused. Jess said "default language should be blank so that they must manually choose the language", which means to me that there is no default. Jess, can you clarify this for us?
(In reply to Dan Poirier [:dpoirier] from comment #13) Yes. No default when we don't have a good option for a default. The issue is that we'll be enabling the page in languages that the newsletters don't support. So, for example, when a user is looking at the page in es-ES, we should preselect Spanish and Spain. But when they're looking at it in zh-CN, we shouldn't pick a default since we don't have newsletters translated into Chinese.
Pmac nailed it. No default when we don't have a good option for a default.
Okay, on the signup form, currently we'll set the initial language based on their locale, but if that locale is not supported by any newsletters, we'll start off with the language set to English. We're going to change that so if their locale's language is not supported by any newsletters, the initial language on the form will not be set.
That's my understanding.
Correct!
QA FYI - Goal for this to go live is tomorrow. We're hoping for this latest piece to be ready for testing today/tomorrow before launch. Pmac/Dan - please update this bug when/where testing can begin. Here are the test scenarios: 1) Make sure you can signup for HTML vs. TXT vs. a few different languages - make sure everything works (ie double opt in is triggered in the right language and format) 2) When you visit a non-newsletter locale (not: en, es, pt-br, de, fr, id, ru or pl) - (ie "it") the language field should be set to blank. Try signing up without selecting language = error message (and you are not added to ET). Select the language and make sure the signup process works with the right email langauge + format combo.
Commit pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/f683e681f92242d599a2e9407a772863c48e5bc9 Bug 892696 - Change default language for /newsletter On /newsletter and footer email forms, if the user's locale is not for a language that our newsletters support, then instead of defaulting the language field to 'en', default to having it not set, to force the user to choose one of the supported languages when subscribing instead of just clicking through and maybe not wanting English but getting it anyway.
This is ready to be QA'ed! Sites to test sign up form in a few different languages + email formats: 1) https://www.allizom.org/b/id/newsletter/ (make sure language is ID - then proceed) 2) https://www.allizom.org/b/it/newsletter/ (make sure language is blank - then proceed) 3) https://www-dev.allizom.org/b/zh-TW/firefox/fx/#footer-email-form (make sure language is blank - then proceed)
1 and 2 should also be for www-dev.
Tested all on www-dev. Language is NOT blank for /it/newsletter or /zh-TW/firefox/fx/#footer-email-form.
rbillings is running through tests more on IRC. Language is showing as Blank! She's making sure that non-EN works on those pages too and will confirm here if all's good.
Re-tested and languages & emails & ET info are all as expected.
Sweet! I think we're all good to go live. Please make sure that rbillings and I are around before this goes live so that we can be on deck to test.
Commit pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/1564f51336089f9d5114a6177641559f339590bc Bug 892696: Point all locales to bedrock for /newsletter/. Also fix some l10n issues with _lazy and error messages.
This looks great on prod! Currently available: csb, de, es-ES, fr, hu, id, pl, pt-BR, ru Pmac is going to unleash all available/finished localized locales today if possible. (especially to get all the es versions live :) )
Added the following in r118191. bg, bn-BD, cs, cy, da, el, en-GB, eo, es-AR, es-CL, es-MX, et, eu, fa, fy-NL, hr, is, it, ko, lij, lt, mk, ms, nl, ro, sk, sl, son, sq, sr, sv-SE, ta, te, zh-CN, zh-TW
Whiteboard: r=117989,118007 → r=118191
Let me know if this list looks good and I'll merge to prod tonight or tomorrow.
Flags: needinfo?(jdavis)
Rock-n-roll - those all look great as long as all 52 strings are localized for those locales. Merging them to prod = no need to test so much as that page is now live in those locales...right?
Flags: needinfo?(jdavis)
Yeah, I got that list from the ones on pascal's link for which all 52 strings were translated. The page will be live in these locales as soon as I merge this change to prod. Currently they're only on dev, but that server ignores the active lang file tags, so it's no different there. Though you can go to the URLs on dev and see the pages.
Perfect! let me know when all's live on prod :)
Committed to prod in r118217. Should be live in a few minutes.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Looks and works great! :D Thanks team!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.