Closed Bug 336338 Opened 18 years ago Closed 18 years ago

"View more information about this update" doesn't display localize page

Categories

(AUS Graveyard :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
4.x (triaged)

People

(Reporter: sugar.waffle, Assigned: preed)

References

()

Details

(Keywords: fixed1.8.1, l12y, Whiteboard: [mustfix][server side])

Attachments

(1 file, 1 obsolete file)

In software update dialog, when "View more information about this update" is clicked, the page that does localize is not displayed. 
I think that it should display the page that localize. 
(Especially, the Japanese thinks that it likes localize page)

Reproducible: Always

Steps to Reproduce:
1. Install Firefox1.5.0.1 L10N package and create new profile.
     e.g. Firefox1.5.0.1-ja-JP-mac
2. Start Firefox
3. Select  Help --> Check update
4. Click "View more information about this update" on software update dialog

Actual Results:
An English page is displayed. 
http://www.mozilla.com/firefox/releases/1.5.0.3.html

Expected Results:
The localize page is displayed. 
http://www.mozilla-japan.org/products/firefox/releases/1.5.0.3.html

Mac OS X 10.3.9
Flags: blocking-firefox2?
Keywords: l12y
Assuming all the localised pages are available at release time, this could be handled by specifying the appropriate detailsURL for each locale in the served update.xml file. That makes it a build engineering problem rather than something for localisers to handle.
OS: Mac OS X 10.3 → All
Hardware: Macintosh → All
I think, at best, we can use the app.update.url.details value like we do for the release notes, instead of specifying in the update.xml, and that should in fact work based on reading the code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: --- → Firefox 2 beta1
Version: 1.5.0.x Branch → 2.0 Branch
Assignee: nobody → jminta
preed says this could be fixed server-side by sniffing for preferred language.  The other option is to just not send an update-url when we send update data and then we'll default to app.update.url.details (see http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/src/nsUpdateService.js.in#770).  mconnor, do you have an opinion on the best solution here?
Whiteboard: swag:0.5d
I think we should just not send the update URL in the update system, since the we want to point to the same place as the Release Notes menuitem anyway, and the fallback is to do that.

-> preed for changes to the AUS bits, since this is a build/release issue now.
Assignee: jminta → preed
Attached patch switch to release notes url (obsolete) — Splinter Review
This should be the patch to fix things on the client side, but we'll still get tripped up by the server if they pass in an update.  In reference to preed's question from wednesday: pl, nl, and ko override releaseNotesURL on trunk l10n.  It appears that a few additional locales override it for thunderbird.
http://lxr.mozilla.org/l10n/search?string=releaseNotesURL

Not asking for a review/smoke-testing this patch until we finalize the direction we want to go.
This patch doesn't change the behaviour other than to change the url we fallback
to from the release page to the particular release page.

A real patch should remove the const we don't use anymore as well as the obsolete
l10n string.

The website URL is something that Phil may want to think about, too.
Whiteboard: swag:0.5d → swag:0.5d 181b1+
I've discussed this issue with several people, and I was going to propose a standard URL type for virtually all mozilla.com content.  In this example:

http://www.mozilla.com/firefox/releases/1.5.0.3/?lang=jp

Which I think has the following benefits:

- the domain is always the same, so there are never any problems with LANG.mozilla.com not existing for a new locale

- the server has the option of parsing the user-agent, the Accept-Language header, or the query argument

- if the language isn't supported, it can trivially fall back to English or a language-specific "Sorry, we don't have content for your language" page

- it's automatic, and reduces the localization burden, as there is no per-locale URL to maintain

Are there any negatives to this proposal that we are not seeing?
Preed: is Phil's proposal a huge amount of work to support, server-side?
(In reply to comment #8)
> Preed: is Phil's proposal a huge amount of work to support, server-side?

That's a question for morgamic and wclouser, but I shouldn't think so.

I think it would be easier to use Accept-Language on the server-side (all of the "graceful fallback" stuff is part of http, so I don't see a reason to put it in the URL, but maybe it's just another method to get to that content?) as opposed to changing URLs, but that's just me.
(In reply to comment #9)
> 
> I think it would be easier to use Accept-Language on the server-side (all of
> the "graceful fallback" stuff is part of http, so I don't see a reason to put
> it in the URL, but maybe it's just another method to get to that content?) as
> opposed to changing URLs, but that's just me.

I was advised that Accept-Language is harder to work with on the application side, and that it's more sensitive to user tweaks (like extensions that change the user-agent to match IE, and some user preferences), versus a URL argument that one can easily mod_rewrite.

But all that being said, I'm on board with whatever similar solution is most appealing to the infrastructure maintainers and application developers.
Most of the localized sites I've seen have had the lang flagged in the URI at some point -- though not all by a query string variable.

We've seen most of them designate the language somewhere in the path, for example:
http://www.mozilla.com/JP-jp/firefox/releases/1.5.0.3/

The URI format you mentioned would work just fine, but it might be cleaner to designate a consistent place for the locale information and use a top-level rewrite to avoid having to tack on query string variables on the end of every URI.

Some concerns might be:
* How using a query variable might affect search engines, etc.
* How using a path and rewrite approach (first suggestion) might mess up all incoming links for existing pages
(In reply to comment #9)
> I think it would be easier to use Accept-Language on the server-side (all of
> the "graceful fallback" stuff is part of http, so I don't see a reason to put
> it in the URL, but maybe it's just another method to get to that content?) as
> opposed to changing URLs, but that's just me.

It's a lot harder to control Accept-Language for testing and such than to control a URL, and it's harder to rewrite efficiently based on headers than on URL components, so I'm all for the URL/path approach.

(I prefer path components to query strings, too, because it makes it a lot easier to just generate static content appropriately instead of having to run code on each request.)
We're in the situation of getting *a lot* more minority languages.
I'm not sure if we really want to admin web content in all those languages.
A bit of server side php sounds like less work to me.

Maybe this is part of the "oops, what did we want to do to mozilla.com intl for real?" bigger-picture. Or just hints at how big that picture is.

Regarding the url vs. accept_lang discussion, quite a few sites do both. I.e., if you go to the root, you get redirected to a URL-encoded language specific version depending on accept_lang.
(In reply to comment #13)
> We're in the situation of getting *a lot* more minority languages.
> I'm not sure if we really want to admin web content in all those languages.
> A bit of server side php sounds like less work to me.

Not following -- which of these options would prevent us from doing server-side processing if we needed to?  (I meant static pages from the perspective of how they're produced to serve up to each user, not that they would be maintained manually.)
I posted to .planning to take the url discussion out of bugzilla and sync it with bug 314119.
(In reply to comment #5)
> In reference to preed's
> question from wednesday: pl, nl, and ko override releaseNotesURL on trunk l10n.

Actually, we (pl) do not override releaseNotesURL in trunk Firefox, we had only forgotten to update it to .com there. This has recently been fixed.

http://lxr.mozilla.org/l10n/source/pl/browser/chrome/browser-region/region.properties#1

Accept-Language seems the best solution, but there should be a way to override it (e.g. a link in the page footer showing available languages). 

Overriding user agent string doesn't change the Accept-Language setting.
--> beta2, but we need to come to a solution on this sooner rather than later so we can test with nightly updates ...
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Preed, what were your thoughts on this again?  I should have taken notes...
Whiteboard: swag:0.5d 181b1+ → [at risk]
(In reply to comment #18)
> Preed, what were your thoughts on this again?  I should have taken notes...

From the build side, it's easy to publish updates with no details URL. It's also easy to publish a "localized" URL, i.e. a details URL pointing to a URL with the locale string in it somewhere (either as a part of the URL, or in the query string).

For the rest of it, I think server-side is the way to go, and I think Accept-Language is the solution for this problem. But that's someone else's sandbox, so... whatever is easiest for them is fine with me.
(In reply to comment #17)
> --> beta2, but we need to come to a solution on this sooner rather than later
> so we can test with nightly updates ...

(In reply to comment #19)
> For the rest of it, I think server-side is the way to go, and I think
> Accept-Language is the solution for this problem. But that's someone else's
> sandbox, so... whatever is easiest for them is fine with me.

I think we settled on making the first component of the path the locale, because that can be trivially mod-rewritten.  wclouser ran some numbers to see what kind of server overhead that induces, but I haven't heard the final results yet.

So instead of what I wrote in comment #7, we get:

http://www.mozilla.com/jp/firefox/releases/1.5.0.3/
What needs to happen on the client side to make this happen?
Whiteboard: [at risk] → [mustfix]
(In reply to comment #21)
> What needs to happen on the client side to make this happen?
> 

Resolve http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/44b80aee0f9c664a/e33c4c1fb3763bef?lnk=raot#e33c4c1fb3763bef, which is pending on Wil Clouser testing, AFAICT. That is blocking quite a few of these bugs.
(In reply to comment #21)
> What needs to happen on the client side to make this happen?

If we're talking about publishing a details url for the updates that includes the locale in the URL, i.e. http://www.mozilla.com/$locale/firefox/releases/1.5.0.3/, we can do that on the server (via AUS2) side, no client change necessary.
Ok, if that's how you want to resolve this, moving to AUS.
Assignee: preed → morgamic
Component: Software Update → General
Product: Firefox → AUS
QA Contact: software.update → general
Target Milestone: Firefox 2 beta2 → ---
Version: 2.0 Branch → 2.0
Attachment #225889 - Attachment is obsolete: true
(In reply to comment #24)
> Ok, if that's how you want to resolve this, moving to AUS.

I figure less client changes at this point = less risk at this point.

I'll take this back from morgamic, since this should be a patcher2 change, not an AUS change.
Assignee: morgamic → preed
Preed/Morgamic - ping on this as we are coming up on the RC1 for FF2...
(In reply to comment #26)
> Preed/Morgamic - ping on this as we are coming up on the RC1 for FF2...

I asked Beltzner about this, and we weren't going to have localized content for the updates we sent out.

This will require a patch to patcher2, but it'll be really minor. We can do this for rc1, but I'll need to know what the (localized) URL(s) need to be for rc1.
Whiteboard: [mustfix] → [mustfix][server side]
Localize detailsUrls for complete, partial, and past update snippets.

Also, slip in fixes for:

-- the progress meter, which never got incremented during a run
-- Be more explicit about calls to SubtitutePath() which may not be doing what we expect (since we're using it in a number of different ways than we originally were).
Attachment #239694 - Flags: first-review?(rhelmer)
Attachment #239694 - Flags: first-review?(rhelmer) → first-review+
Fixed.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.