Closed Bug 854248 Opened 12 years ago Closed 11 years ago

add client-side locale detection to the download button

Categories

(www.mozilla.org :: Pages & Content, enhancement, P3)

Product:
www.mozilla.org
Component:
Pages & Content
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: pascalc, Assigned: kohei)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [kb=906974])

On the old php site, we had the possibility to have client-side (js) locale detection for our download button. This is something we lost when we moved to python as this js file was generated serverside in php. We need that mostly for buttons on the home page which is not localized and for any page in English exposing a download button but not to be localized or not localized yet. This is also useful for locales we have no web parts at all but already have Firefox builds for (basically, all the new locales when they start entering in the aurora/beta cycle). Assigning to pmac and ccing craig and arky on this one since we talked about it together last week, but feel free to reassign. Thanks
Priority: -- → P3
Blocks: download-buttons
Severity: normal → enhancement
Component: Bedrock → Pages & Content
Is this still required if we starting pointing download buttons to /firefox/new#download-fx where the /new page will do the locale detection?
I think it is needed for all the places that are not the Firefox download page and where we don't have localized pages, but it is less now thanks to the fact that we have a lot more localized content than last year and we have the language selector + the translation bar
(In reply to Pascal Chevrel:pascalc from comment #2) > I think it is needed for all the places that are not the Firefox download > page and where we don't have localized pages, but it is less now thanks to > the fact that we have a lot more localized content than last year and we > have the language selector + the translation bar Why would client-side locale detection be needed in a case like this? If a French-speaking visitor is on a page that is only available in en-US, they click the download button, it points to the /firefox/new/ page, where their French locale is detected and they are served a FR download. Is that not right?
Are all download buttons going to become a link to firefox/new ?
(In reply to Pascal Chevrel:pascalc from comment #4) > Are all download buttons going to become a link to firefox/new ? That seems to be the suggestion over at Bug 874913. cmore?
I'll take a look at this.
Assignee: pmac → kohei.yoshino
Status: NEW → ASSIGNED
Whiteboard: [kb=906974]
Given Bug 874913, there are two options: 1. Make the download buttons locale-neutral. Remove the locale label, change the link from /products/download.html to /firefox/new/#download-fx, then implement a locale detection on /firefox/new/. 2. Implement a locale detection on the download buttons. Keep the locale label, change the link from /products/download.html to /firefox/new/#download-fx&locale={locale} and parse the locale on /firefox/new/.
(In reply to Kohei Yoshino [:kohei] from comment #7) > Given Bug 874913, there are two options: > > 1. Make the download buttons locale-neutral. Remove the locale label, change > the link from /products/download.html to /firefox/new/#download-fx, then > implement a locale detection on /firefox/new/. > > 2. Implement a locale detection on the download buttons. Keep the locale > label, change the link from /products/download.html to > /firefox/new/#download-fx&locale={locale} and parse the locale on > /firefox/new/. Hmmm, I was about to suggest #1, but now that we have the language bar on the bottom and the lang mismatch notification up top, I think this is less of an issue. If we add the locale to the download button like /[locale]/firefox/new/ and the locale does not match the browser's language when they land on /firefox/new/, the user will get prompted to make the change. It really doesn't matter much now and we could just keep it simple and link all users to /firefox/new/ without a locale and have that page redirect to the correct locale. I would rather not introduce &locale= into the mix.
Linking to /firefox/new/ (without locale) sounds good to me. So can we close this bug as WONTFIX?
(In reply to Kohei Yoshino [:kohei] from comment #9) > Linking to /firefox/new/ (without locale) sounds good to me. So can we close > this bug as WONTFIX? I think that should be fine. :pascalc :sgarrity, are you good here?
Flags: needinfo?(pascalc)
I think that we the current set up, we no longer need client-side l10n, thanks
Flags: needinfo?(pascalc)
I think we're set here, yes. I had one question though: If we're relying on the language selector + the translation bar, doesn't this mean that /firefox/new/ must be localized into every local that Firefox is available in, or you won't be able to get the download link (without going to /firefox/all)? Maybe that's already the case - I'm not sure how the l10n coverage of /firefox/new compares to the browser itself.
Overall status of firefox/new http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=all&website=0&file=firefox/new.lang Shipped locales http://hg.mozilla.org/releases/mozilla-release/raw-file/f17cd4055b55/browser/locales/shipped-locales Locales missing firefox/new: ach, as, be, bn-BD, bn-IN, bs, ff, gu-IN, he, kn, lv, mai, ml, or, si Missing firefox/new, not shipping right now: az Other not relevant: ja (I think they have their own website for download)
But note that the locales that we don't have yet on Bedrock have the old (orange) download page served from PHP, so we have all locales covered for the release channel, most of them on Bedrock, a few of them still on the PHP side.
We also have the /firefox/all/ page if there is a language we don't have in bedrock. In a perfect world Firefox locales == locales of /firefox/new/. We don't have every one translated for the page, but collectively we probably have over 90% of the traffic translated in bedrock.
Thanks everyone. We'll go ahead and won't fix this one.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.