This is the SeaMonkey version of bug 454300. In particular, we're still seeing the bug 488856 problem with the URLs from http://hg.mozilla.org/comm-central/file/default/suite/locales/en-US/chrome/branding/brand.properties and getting a cert error on in-client URLs is quite lame... I know support for *.add-ons.mozilla.org was never completely official, but it worked well enough for some time. In any case, we need to switch to other URLs, apparently preferably plain addons.mozilla.org ones, but bug 471834 has open questions as to what to change them to (i.e. it's unclear where/if the version will still be used in the URLs).

Dupe of bug 488856?

(In reply to comment #1) > Dupe of bug 488856? No, as the bug there is fixed but we still have URLs like that in the tree, which are covered here now.

An example would be https://en-US.add-ons.mozilla.org/en-US/SeaMonkey/2.0/extensions/

(In reply to comment #3) > An example would be > https://en-US.add-ons.mozilla.org/en-US/SeaMonkey/2.0/extensions/ Actually, that was my fault, I got some cases wrong. A better example is https://en-us.add-ons.mozilla.org/en-US/seamonkey/2.0/themes/ - and this happens to be what View > Apply Theme > Get New Themes is calling currently. If we just change the .org to .com, it works, see https://en-us.add-ons.mozilla.com/en-US/seamonkey/2.0/themes/ (the page that comes up looks bad because of bug 513227 but that's on the AMO side).

Need this for 2.0 final.

BTW, the other links - besides the themes one from the View menu - are not exposed in the UI any more, extensions.js does this: var showGetMore = false; var getMore = document.getElementById("getMore"); if (prefURL && !gShowGetAddonsPane) { [... set showGetMore to true on other conditions ...] } as gShowGetAddonsPane is always true for us - we show the "Get Add-ons" pane - we never show the links in add-ons manager, and that's the place they would be there for (we just re-used one of them in the view menu).

I moved the part that actually blocks 2.0 to bug 517596 - this will stay here for removing the locale-specific domains later.

Comment on attachment 415890 [details] [diff] [review] (Av1) Update the urls to their current redirections Use the words for the types like in the Firefox patch. Don't use the actual type numbers.

Comment on attachment 415890 [details] [diff] [review] (Av1) Update the urls to their current redirections >-#define seamonkey_l10n >+#define seamonkey_l10n > > # LOCALIZATION NOTE (seamonkey_l10n_long): > # insert full bookmark line for localized SeaMonkey page (normal bookmark) >-# e.g. #define seamonkey_l10n <DT><A HREF="http://www.seamonkey.tld/">tlhIngan Hol SeaMonkey</a> >-#define seamonkey_l10n_long >+# e.g. #define seamonkey_l10n_long <DT><A HREF="http://www.seamonkey.tld/">tlhIngan Hol SeaMonkey</a> >+#define seamonkey_l10n_long ...and don't change the whitespace on those #defines, from all I remember, that space is actually necessary for this to work correctly. Nice catch on the comment, though. :)

Per comment 9. brand.properties: *I dropped the 'extensions/' part too, per current redirection and to be in sync' with the 2 other files. *Can't we replace '%LOCALE%/%APP%' by 'en-US/seamonkey' like in bookmarks.inc?

Per your comment 10. See my comment 11 too.

Comment on attachment 415899 [details] [diff] [review] (Av2a) Update the urls to their current redirecting aliases, Fix some nits too >-# LOCALIZATION NOTE (seamonkey_themes): >-# link title for https://en-US.add-ons.mozilla.com/en-US/seamonkey/themes >-#define seamonkey_themes SeaMonkey Themes No reason to move that one around, please leave it where it was. > # LOCALIZATION NOTE (seamonkey_l10n): >+# (Double-)Space value is needed as-is by default. That comment is confusing for localizers, please just leave it out. If localizers actually use this line to define something non-empty, they want a single space to separate the key and value, else they should just leave it unchanged to what en-US has.

What about my comment 11 question?

Only bookmarks.inc can use 'en-US/seamonkey', if you mean that, because it's just comments there. Everything else needs to go with the '%LOCALE%/%APP%' stuff, esp. because all locales can use exactly the same values and get the right thing.

Per your comment 14. Thanks for the explanation/confirmation.

Comment on attachment 415959 [details] [diff] [review] (Av3) Update the urls to their current redirecting aliases, Fix some nits too [Checkin: Comment 18 & 19] http://hg.mozilla.org/comm-central/rev/663c9fb21ea2 "approval-seamonkey2.0.1=?": Should really be wanted, unless these urls are considered l10n strings...

Comment on attachment 415959 [details] [diff] [review] (Av3) Update the urls to their current redirecting aliases, Fix some nits too [Checkin: Comment 18 & 19] http://hg.mozilla.org/releases/comm-1.9.1/rev/e62adbd5b4f7