Closed Bug 357371 Opened 13 years ago Closed 7 years ago

update URL used for default Google Reader plugin


(Firefox Graveyard :: RSS Discovery and Preview, defect)

2.0 Branch
Not set


(Not tracked)



(Reporter: beltzner, Assigned: Gavin)




(Keywords: verified1.8.1.4)


(1 file)

We have been asked by the Google Reader PM to update the URL that's used for passing RSS feeds to that service. The L10N requirements (see URL) need to be updated as well to reflect Google's requested locale parameter of hl=%locale%.

The new URI to be used is:{LL}&client=firefox

where {LL} is the two letter locale code.
Looking to make this an update for
Flags: blocking1.8.1.1?
Moving flag to wanted1.8.1.x -- Brian, can you confirm that this is still the URL format we want and that things are ready on Google's server side for us to make this change?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
To add some context here, there's a couple of problems that we're trying to address:

1. Google Reader and Google Homepage are potential targets for RSS feeds.
2. Google Reader isn't available in all locales.

My feeling is that with the locale code, we should interpret this URL to mean "add it to Google Reader" for all locales where Google Reader exists, and "add it to Google Homepage" for those where it does not. This is because Google Reader is really Google's online RSS reading service, adding RSS as a portlet on the Google Homepage is a nice thing to be able to do, but I don't think it qualifies as a "Feed Reader" interface unless there's nothing better. Google can also make it easy to add "Google Homepage" to the list of Feed Readers using the add web based feed reader APIs (see for details)

Brian: does that logic make sense to you?
(In reply to comment #3)
> Brian: does that logic make sense to you?

Our plan was actually to give users the choice on the subscribe page hosted at Google when we offer both products. I think there are different use cases for each product. We have also discussed a server side pref to remember the user's choice.
Today I noticed that the URL suggested by Google DOES NOT add my feeds to Google Reader anymore, only to Google Homepage (/ig). That's probably something with locales because I switched to russian Firefox.

This is very frustrating. Why not use the good old*/feed/%s ?

It works no matter what locale the browser uses and never suggests the annoying Google Homepage thing.
I spoke with Nick Baum from Google (no bugmail ID yet, will cc him once there is one) and the asks from Google are:

1) Update the URL as per this bug
2) Change the name in the list of feed readers to "Google"
Flags: blocking1.8.1.3?
Guessing at assignee
Assignee: nobody → sayrer
Flags: blocking1.8.1.4? → blocking1.8.1.4+
no, someone from browser/ would be better
Assignee: sayrer →
Nick: can we get confirmation that the URL Google wants to have used in all locales of Firefox 2.0.0.x is:{LL}&client=firefox

where {LL} is a two-letter locale code? 

Also, could we get a list of the two-letter locale codes you support, and how you'd like us to map our locales against those? I believe that we're currently using the ones listed here:

Mike, "we currently use" isn't really clear to me, where would we be using that?

Note, any change request to the {LL} sent by a particular localization would require a full blown bug report if we need to send them through the client. We should probably have some QA plan for this, too.
Hi all,

Mike's <a href="">comment #9</a> is right on. The new url is correct, as are the locales, and the text of the link should be changed to "Google" (rather than Google Reader).

Alex — we're choosing to hide Google Reader for non-English locales since it isn't internationalized yet. Once Google Reader internationalizes, it will appear as an option for all locales. Also, once the text changes from "Google Reader" to "Google", you will be able to add a new option that takes you directly to Reader (with the URL you specified).


(In reply to comment #11)
> The new url is correct, as are the locales

A cursory look at the l10n repository seems to indicate that we have 51 locales that have a Google Reader default. Is there a comprehensive list of supported locale codes? If is that list, then there are many locales in our tree that don't have a corresponding Google code. What should be done for those locales, assuming we go the "hardcode the locale code in each localized file"? 

That issue aside, hard coding the locale code in each of those files is far from optimal, and we don't currently have a way to map our in-tree locale codes to supported Google codes. Is it feasible for us to just omit the "hl=ab-CD" parameter and let you handle locale detection on the server side?
I don't think this should block the next minor release, given that we still need to figure out what to do about the locale codes. This, as far as I know, a "good to have" type of change rather than a must-fix.
Flags: blocking1.8.1.4+ → blocking1.8.1.4?
Flags: blocking1.8.1.4?
I see three differing requests here. One is to send hl={LL}, the other one is sending client=firefox, and the last is to send to instead of

The hl part is tricky, and likely a maintainance and QA nightmare. I'm surprised to see this request, too, as for regular searches we're supposed to actually not do that. As it currently doesn't show any impact, it's hard to get our localizers to make an educated decision on this, too.
Changing the user experience here might not be the right thing to do, and needs at least a decent notice and in-depth information to our local communities.

As for the client key and the server name, those don't seem to have any end-user impact and might be easy to fix.
For, we can just change the en-US display name. Changing it for all locales requires more work and coordination with localizers, and we can determine how to proceed with that for
Actually, the name should be changed in all languages where it currently says Google Reader.

Also, changing the url from fusion to www might be doable, no?
(In reply to comment #16)
> Actually, the name should be changed in all languages where it currently says
> Google Reader.
> Also, changing the url from fusion to www might be doable, no?

Those changes require a lot of coordination/verification effort that we won't be able to get done in time for This approach was chosen as a compromise for If you'd rather we hold off and do it all in one shot for a later release, we can do that too.
That's fine, let's change the name for EN-US in Thanks.
Attachment #262949 - Flags: review?(mano)
Attachment #262949 - Flags: approval1.8.1.4?
Comment on attachment 262949 [details] [diff] [review]
en-US only, name change

approved for, a=dveditz for release-drivers if you land today
Attachment #262949 - Flags: approval1.8.1.4? → approval1.8.1.4+
Checked in that en-US name change on the trunk and on the 1.8 branch for

mozilla/browser/locales/en-US/chrome/browser-region/ 	1.22
Keywords: fixed1.8.1.4
verified fixed for the name change (see Comment#18 and #20) using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/2007050106 Firefox/ The Reader is now called Google and no longer Google Reader.

Also tested on Windows Vista/XP and Fedora FC 6. Adding verified keyword
Nick: I'm not sure if it was made clear here before, but due to the way we save the user's choice of a feed reader, any change we make to the URL will only affect users who select Google as their default using the new build (it won't affect those who've already chosen Google unless they re-toggle the preference). I'm not sure if having to continue to support the old URL changes your desire to have the URL changed or not, but I wanted to make sure that was understood.
Hi Gavin,

Thanks for the clarification. We're aware that we'll have to keep supporting the old url — we just want to make sure we have the right information going forward.


Flags: blocking-firefox3?
Flags: blocking-firefox3?
Flags: in-testsuite?
Flags: in-litmus?
Flags: in-testsuite?
Flags: in-litmus?
It sounds like we're not going to end up doing this (reopen or file a new bug if it's still desired).
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.