We need a redirecting service that allows us to now use hard-coded URL strings in Firefox 3 for in-product help. Could this be just a .htaccess file that redirects certain url patterns to the specific article on SUMO?

s/now/not/

Should we use a pref-controlled URI scheme which includes locale and version, like AUS does? app.update.url = https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml

We could use mod_rewrite for this, and yes, it makes sense to follow a URI scheme; it eliminates the need to have any logic in the routing. We could do something like: http://support.mozilla.com/1/%PRODUCT%/%VERSION%/%PLATFORM%/%LOCALE%/ Not sure if we want to use SSL on the link. Are we concerned about man-in-the-middle attacks with support docs?

The question on whether to include the locale into the url or not is somewhat open to the locale choice algorithm. Or not, depending if we can overwrite that on the server. I guess, if we can, we should, to be on the safe side. I.e., include it in the url *and* overwrite it, with user setting, or accept_lang, even. Another thing in the URL, IMHO, should be the helptopic, as given in the preference pane overlays, helpTopic="prefs-main". By keying over the helpTopic itself, we're able to cut too long pages into two by mere server changes later.

(In reply to comment #4) > > Another thing in the URL, IMHO, should be the helptopic, as given in the > preference pane overlays, helpTopic="prefs-main". By keying over the helpTopic > itself, we're able to cut too long pages into two by mere server changes later. > Exactly -- this is important. Currently, the actual location you'll end up with is an anchor of a long article, but we might want to split it up in the future. Basically, every unique helpTopic should have its own mapping, even if it's linking to the same article but different anchors.

http://support.mozilla.com/1/%PRODUCT%/%VERSION%/%PLATFORM%/%LOCALE%/<helptopic>/ makes sense to me, and I think SSL is overkill. That's one fantastic social hack, but social hacks of that complexity are Hard(tm) Thus, we'd get something like http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main/ which I think is easy to mod_rewrite in a bunch of different ways. Is there anything else that seems needed?

Is the version string "3.0" or "3.0.0"? That said, I think we will simply parse for 3* and make sure all 3.x.x versions enables "Firefox 3" view for articles.

Do we need %PRODUCT% if support.mozilla.com is Firefox-only?

Yes, keep it. Don't want to deviate from how other services work.

This page seems to list the current helptopics: http://mxr.mozilla.org/mozilla/search?string=helptopic&find=browser&findi=&filter=&tree=mozilla

which pages should this list of help topics point to?

can I get an authoritative list of help topics and pages they should point to? Thanks.

Chris, it's time that we rename the en-US in-product articles to the target names, e.g. "using_firebird-en-US" -> "Using Firefox". Can you take care of that today and provide the final URIs to point the individual help topics to as defined in http://mxr.mozilla.org/mozilla/search?string=helptopic&find=browser&findi=&filter=&tree=mozilla) Thanks!

Establishing the target names shouldn't be a problem today. There are a few articles that we need to combine with current KB articles, and maintaining links/associations will need testing on stage. I don't think that can be finished today, but I can make it P1 after the list is established.

As discussed on IM, we will rename any conflicting articles, then rename the *-en-US articles to their target (Fx2) names, and then we will have a full list of helptopic -> URI list here.

pageinfo_general http://support.mozilla.com/kb/Page+Info+window prefs-main http://support.mozilla.com/kb/Options+window#main_options prefs-clear-private-data http://support.mozilla.com/kb/Options+window#private_data prefs-fonts-and-colors http://support.mozilla.com/kb/Options+window#fonts_and_colors prefs-privacy http://support.mozilla.com/kb/Options+window#privacy_options prefs-applications http://support.mozilla.com/kb/Options+window#applications_options prefs-connection-settings http://support.mozilla.com/kb/Options+window#connection_settings prefs-tabs http://support.mozilla.com/kb/Options+window#tabs_options prefs-advanced-javascript http://support.mozilla.com/kb/Options+window#advanced_javascript prefs-languages http://support.mozilla.com/kb/Options+window#languages prefs-content http://support.mozilla.com/kb/Options+window#content_options prefs-security http://support.mozilla.com/kb/Options+window#security_options prefs-advanced-general http://support.mozilla.com/kb/Options+window#advanced_general prefs-advanced-network http://support.mozilla.com/kb/Options+window#advanced_network prefs-advanced-update http://support.mozilla.com/kb/Options+window#advanced_update prefs-advanced-encryption http://support.mozilla.com/kb/Options+window#advanced_encryption

mconnor, do we use a helptopic for the main page as well? I.e. when you're selecting Help > Firefox Help from the menu.

"For Internet Explorer Users" http://support.mozilla.com/kb/For+Internet+Explorer+Users

I have assumed that the helptopic for "For Internet Explorer Users" is ieusers If this is incorrect. let me know.

So, what we're missing to get this checked in are: * helptopic/entry rule for start page (http://support.mozilla.com/%LOCALE%/kb/Firefox+Help) * helptopic/entry rule for "For Internet Explorer Users" (http://support.mozilla.com/%LOCALE%&kb/For+Internet+Explorer+Users)

> So, what we're missing to get this checked in are: > * helptopic/entry rule for start page That's "firefox-help". > * helptopic/entry rule for "For Internet Explorer Users" And that's "ieusers", see http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/base/content/baseMenuOverlay.xul&rev=1.17&mark=80,93#79 But that code (and the code in preferences.xml) needs to be changed anyway to open a new tab with the sumo page instead of the help viewer. Do we have a bug for that already?

Thanks Steffen for the info! This is now implemented on support.mozilla.com. Example: http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main

Can we please change the platform part like so: WINNT (for Windows NT, 2000, XP and later) Linux (for all Linux versions) Darwin (for all MacOS X versions) Because those are the values returned by the url formatter for %OS%. And can we ignore the "b5pre" in the version part, i.e. ignore parts of the string starting with "a" or "b"?

mconnor's patch in bug 423486 will take care of the version part, so no need to change that. The change to the platform part is still needed though.

I think we're ignoring the platform bit anyway, unless I'm wrong?

That's actually a bug that should be fixed, IMHO. The platform dependent firefox 3 content is there, we show firefox 2 windows, though.

(In reply to comment #25) > I think we're ignoring the platform bit anyway, unless I'm wrong? > Where is it ignored you mean? SUMO uses the platform bit to set the content customization filter for an article (win/mac/linux).

If I open this link on Windows, the windows version is displayed: http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main

To add, the sumo redirects seem to ignore both platform and version, but sumo picks them up again from the useragent. The fx3 mac link here gets me to fx2 windows prefs, if I open it in Firefox 2.0.0.12 on windows, and to mac fx3 options if I open it in minefield on my mac. I.e., I see preferences vs options, and the applications options only if I open the link from a fx3.

Oops, my bad. Yes, we currently ignore the url parts specifying os/version because we use js to show/hide content anyway, so we can might as well use js to detect stuff. If this is a bad idea for other reasons (such as browser UA spoofing), this should be easy to fix.