Last Comment Bug 336338 - "View more information about this update" doesn't display localize page
: "View more information about this update" doesn't display localize page
Status: RESOLVED FIXED
[mustfix][server side]
: fixed1.8.1, l12y
Product: AUS
Classification: Server Software
Component: General (show other bugs)
: 2.0
: All All
: -- enhancement (vote)
: 4.x (triaged)
Assigned To: J. Paul Reed [:preed]
:
Mentors:
http://lxr.mozilla.org/mozilla/source...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-02 17:15 PDT by Hiro
Modified: 2006-10-23 15:43 PDT (History)
16 users (show)
mconnor: blocking‑firefox2+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
switch to release notes url (1.35 KB, patch)
2006-06-16 10:56 PDT, Joey Minta
no flags Details | Diff | Splinter Review
Localize the detailsUrl in the update snippets (9.31 KB, patch)
2006-09-22 12:49 PDT, J. Paul Reed [:preed]
rhelmer: first‑review+
Details | Diff | Splinter Review

Description Hiro 2006-05-02 17:15:13 PDT
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
Comment 1 Nick Thomas [:nthomas] 2006-05-03 01:21:09 PDT
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.
Comment 2 Mike Connor [:mconnor] 2006-05-23 21:25:20 PDT
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.
Comment 3 Joey Minta 2006-06-01 15:40:19 PDT
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?
Comment 4 Mike Connor [:mconnor] 2006-06-12 07:55:25 PDT
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.
Comment 5 Joey Minta 2006-06-16 10:56:57 PDT
Created attachment 225889 [details] [diff] [review]
switch to release notes url

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.
Comment 6 Axel Hecht [:Pike] 2006-06-16 11:52:59 PDT
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.
Comment 7 Phil Schwan 2006-06-27 21:08:03 PDT
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?
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2006-06-28 00:54:43 PDT
Preed: is Phil's proposal a huge amount of work to support, server-side?
Comment 9 J. Paul Reed [:preed] 2006-06-28 10:03:26 PDT
(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.
Comment 10 Phil Schwan 2006-06-28 10:18:13 PDT
(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.
Comment 11 Michael Morgan [:morgamic] 2006-06-28 10:22:01 PDT
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
Comment 12 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-06-28 12:32:07 PDT
(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.)
Comment 13 Axel Hecht [:Pike] 2006-07-03 11:08:29 PDT
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.
Comment 14 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-07-04 04:46:32 PDT
(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.)
Comment 15 Axel Hecht [:Pike] 2006-07-04 07:34:11 PDT
I posted to .planning to take the url discussion out of bugzilla and sync it with bug 314119.
Comment 16 Marek Stępień [:marcoos, inactive] 2006-07-04 11:39:34 PDT
(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.
Comment 17 Mike Beltzner [:beltzner, not reading bugmail] 2006-07-05 12:34:19 PDT
--> beta2, but we need to come to a solution on this sooner rather than later so we can test with nightly updates ...
Comment 18 Mike Connor [:mconnor] 2006-07-18 09:44:50 PDT
Preed, what were your thoughts on this again?  I should have taken notes...
Comment 19 J. Paul Reed [:preed] 2006-07-18 14:42:58 PDT
(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.
Comment 20 Phil Schwan 2006-07-18 20:51:41 PDT
(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/
Comment 21 Mike Connor [:mconnor] 2006-07-24 12:22:21 PDT
What needs to happen on the client side to make this happen?
Comment 22 Axel Hecht [:Pike] 2006-07-24 12:29:27 PDT
(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.
Comment 23 J. Paul Reed [:preed] 2006-07-24 13:47:40 PDT
(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.
Comment 24 Mike Connor [:mconnor] 2006-07-26 19:09:41 PDT
Ok, if that's how you want to resolve this, moving to AUS.
Comment 25 J. Paul Reed [:preed] 2006-07-26 21:42:54 PDT
(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.
Comment 26 Mike Schroepfer 2006-09-05 18:57:09 PDT
Preed/Morgamic - ping on this as we are coming up on the RC1 for FF2...
Comment 27 J. Paul Reed [:preed] 2006-09-05 19:00:56 PDT
(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.
Comment 28 J. Paul Reed [:preed] 2006-09-22 12:49:04 PDT
Created attachment 239694 [details] [diff] [review]
Localize the detailsUrl in the update snippets

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).
Comment 29 J. Paul Reed [:preed] 2006-09-28 21:32:41 PDT
Fixed.

Note You need to log in before you can comment on or make changes to this bug.