There are a bunch of profile files in browser/locales/en-US that are hard, we can partly just remove them, or generate them from defines files, like bookmarks.html. I have a patch in progress, including scripts to generate the necessary new l10n files.

Sorry, Ted, another one for your queue. I ran the essence of this patch by beltzner, dietrich, and I think myk, too. What remains are the build changes to actually implement it ;-) We're dropping the ability to ship microsummary generators, never did that, and won't. We're dropping bookmarks.html in favor of a defines file. That might actually help us if we ever move over to ship a default sql file to bootstrap places, and takes away the mess of asking localizers to localize the URLs. There is one caveat here, ja-JP-mac uses 'ja' as locale for the links, thus the little dance there. mimetypes.rdf and localstore.rdf didn't contain any platform or locale dependent information for ages, so I'm just moving them over to generic. Food for :bs to kill even further, I guess. I included my script to generate bookmarks.inc from bookmarks.html, in case we need that for new locales coming in, and I rather have it in the tree than just on my disk. Tested on merged locales, too. I'll release an update to compare-locales shortly to not merge defines files for now, as I currently don't support to keep the unfilter at the bottom. That version is on the buildmachinery already, though.

The corresponding bookmarks.inc files for all locales are in this zip. With unzip bookmarks.inc.zip ja/browser/profile/bookmarks.inc you can extract the one for your locale.

Requesting blocking, at least bookmarks.html is a pita for new locales.

Comment on attachment 345696 [details] [diff] [review] clean up profile data to be mostly generic, with conversion script for bookmarks +libs:: bookmarks.inc generic/profile/bookmarks.html.in + $(SYSINSTALL) -D $(FINAL_TARGET)/defaults/profile + $(PYTHON) $(topsrcdir)/config/Preprocessor.py \ + -I $< \ + -DAB_CD=$(NO_JA_JP_MAC_AB_CD) \ + $(srcdir)/generic/profile/bookmarks.html.in \ + > $(FINAL_TARGET)/defaults/profile/bookmarks.html Seems like it'd make more sense to have: libs:: $(FINAL_TARGET)/defaults/profile/bookmarks.html $(FINAL_TARGET)/defaults/profile/bookmarks.html: bookmarks.inc generic/profile/bookmarks.html.in ... +install:: bookmarks.inc generic/profile/bookmarks.html.in Similarly here. +++ b/browser/locales/generic/extract-bookmarks.py Should slap a tri-license header on this if you're going to stick it in the tree.

Note, while this is technically a break of string freeze, it's just shuffling existing strings from here to there. Thus I intend to land this after we ship B2, when me landing changes in repos is going to cause less friction for the folks rushing towards b2 right now. I'll aggressively make noise in the .l10n newsgroup for that.

Note to self, this should pick up the ICON remove from attachment 347240 [details] [diff] [review].

b2 is done, shall we get this in ASAP?

Comment on attachment 345696 [details] [diff] [review] clean up profile data to be mostly generic, with conversion script for bookmarks <https://add-ons.mozilla.com/@AB_CD@/firefox/bookmarks/> doesn't seem to work. I tested it for fa, de, and fr, and all of them just redirect to the en-US AMO page. The fix would be simple: s/add-ons.mozilla.com/addons.mozilla.org/ Axel, could you please fix this before landing it? I had manually fixed this for fa, but with this patch localizations don't even have a chance for manually fixing this.

Ehsan, that's a different bug and wouldn't be a regression of this patch. The trick is that the .com redirect actually redirects you to a language based on your accept-lang headers. Which, as you found a redirect setting that doesn't, actually seems to be a bug on how the redirects are set up, or which we're using. We might want to fix this server side or not, which we can do much easier now that the bookmarks links are centralized. Changing the domains where locales link to wasn't supposed to happen in the old scheme either, so I'll defer changes here to a new bug.

I think it would be better to fix this on the server. I filed bug 468424 for that. If that can't be done, I'll file another bug to fix this in the code.

This bug does not depend on bug 468424, unsetting dependency.

Adressing the review comments. I factored the two bookmark rules into one pattern rule and two empty rules for libs:: and install::, which makes things look nicer.

Comment on attachment 351881 [details] [diff] [review] address review comments >diff --git a/browser/locales/en-US/profile/bookmarks.inc b/browser/locales/en-US/profile/bookmarks.inc >+# LOCALIZATION NOTE (bookmarks_addons): >+# link title for https://en-US.add-ons.mozilla.com/en-US/firefox/bookmarks/ Oh, but that comment is wrong, it's actually https://ab-CD.add-ons.mozilla.com/ab-CD/firefox/bookmarks/ (or in whatever way you want to tell people that the page in their locale is going to be used).

Did you see the initial comment? I don't see a good reason pointing to ab-CD pages which refer a non-existing locale code over en-US. Both need a comment that the actual URL will point somewhere else. Landed on mozilla-central, http://hg.mozilla.org/mozilla-central/rev/5ef605914426

Oh, right. Hmm, it's easy to not read over that one, but I'm not sure how to make it really better.

Comment on attachment 351881 [details] [diff] [review] address review comments Requesting approval for 3.1

Comment on attachment 351881 [details] [diff] [review] address review comments Landed with a=blocker3.1 on mozilla-1.9.1, http://hg.mozilla.org/releases/mozilla-1.9.1/rev/dd4e20904f67.