> browser/locales/en-US/searchplugins/answers.xml > browser/locales/en-US/searchplugins/creativecommons.xml We don't ship these in en-US, and probably shouldn't be shipping them in any locales (though many apparently still do, e.g.: http://mxr.mozilla.org/l10n-mozilla-release/search?string=answers&find=list.txt), so they can be removed.

flod: not sure how to interpret your bug 990799 comment 4. Are you suggesting we can't do this?

Reporting the comment to avoid jumping in and out, also CCing Pike who might know more. > And we have one more problem. > http://mxr.mozilla.org/l10n-mozilla-release/search?string=answers&find=list.txt > > Most of these locales are inactive, not sure how we can move fixes to > release (unless I simply land the change there, but I have no idea if the > build system will simply ignore that). 1st issue: before removing those searchplugins, we need to make sure that not a single locale is using them. If you remove the searchplugin from en-US, the locale's build will be busted. Simple as that. I had this discussion with Pike in the past: if we fix a searchplugin is definitely OK to do it without localizers' approval, if we remove or add searchplugins it's "on the edge" (more "not OK"). True also that all those locales have those searchplugins because they used the en-US defaults at the time. 2nd issue (for which I don't have an answer): several of those locales are inactive, which means there are no updates to the localization and we don't have new sign-offs on Aurora or Beta channel. @Pike: what happens if I land a change directly on the release channel? Will the the build system pick it up or ignore it because there's no updated sign-off?

So: This should ride the trains, so let's not bother about release channels until things get there. There are locales that are easy, 'cause NPOTB, and those that are hard, 'cause they're building, and they'd break. Building with answers: fa ga-IE ku mk si zu Non-building with either: mn ne-NP nr rw ss st ta-LK tn ts ve x-testing creative-commons is a bigger set, but also brokken. For locales with beta builds, we'll actually need an updated sign-off to not break beta builds. That's quite a bit of administrational hassle, which I'd prefer to fix organically, instead of putting a lot of flod's work into it. I'd be happy to just tackle the long list of non-building locales first, though, so that we can actually scope our conversation without false-positives.

Answers http://mxr.mozilla.org/l10n-mozilla-aurora/search?string=answers%24&regexp=on&find=browser%2Fsearchplugins%2Flist&findi=&filter=^%5B^\0%5D*%24&hitlimit=&tree=l10n-mozilla-aurora Fixed locales (9): ne-NP, nr, rw, ss, st, tn, ts, ve, x-testing Remaining locales (6): fa, ga-IE, ku, mk, si, zu Creative Commons http://mxr.mozilla.org/l10n-mozilla-aurora/search?string=creative&find=browser%2Fsearchplugins%2Flist&findi=&filter=^%5B^\0%5D*%24&hitlimit=&tree=l10n-mozilla-aurora Fixed locales (11): mn, ne-NP, nr, rw, ss, st, ta-LK, tn, ts, ve, x-testing Remaining locales (18): as, cy, eo, es-AR, eu, ga-IE, gl, ku, mk, mr, si, ta, te, th, vi, zh-CN, zh-TW, zu Not sure how we want to move from here.

As you noticed from the bugspam I started filing bugs to clean up l10n repositories. Sadly, that doesn't ensure that these changes will reach mozilla-release in a short period: if a locale is not updated, we keep shipping the existing signed-off changeset, so the branch to monitor would be mozilla-release, together with the list of shipping locales. http://hg.mozilla.org/releases/mozilla-release/file/default/browser/locales/shipped-locales Answers http://mxr.mozilla.org/l10n-mozilla-release/search?string=answers%24&regexp=on&find=browser%2Fsearchplugins%2Flist&findi=&filter=^%5B^\0%5D*%24&hitlimit=&tree=l10n-mozilla-release Creative Commons http://mxr.mozilla.org/l10n-mozilla-release/search?string=creative&find=browser%2Fsearchplugins%2Flist&findi=&filter=^%5B^\0%5D*%24&hitlimit=&tree=l10n-mozilla-release

One more note: when we decided to ship DDG, the build system was modified to survive in case of missing XML files (bug 1073212). Given the amount of changes to the makefile, especially bug 1194265 and bug 1162569, it would be nice to confirm this is still the case before finding issues in Beta or Release. https://hg.mozilla.org/mozilla-central/log/default/browser/locales/Makefile.in

Marking as dupe of bug 1215413, since a fix landed there.