I received a warning for an unknown file in /searchplugins for Fennec http://hg.mozilla.org/releases/l10n/mozilla-aurora/es-ES/file/a06b594d6601/mobile/searchplugins/list.txt.txt It landed here http://hg.mozilla.org/releases/l10n/mozilla-aurora/es-ES/rev/a06b594d6601 Did you move to Pootle? Only for Fennec? Dwayne, this file sounds like a Pootle's bug.
Making NI explicit for Pootle, since it shouldn't touch anything in /searchplugins, unless something changed with the last update.
This commit broke thing badly, I'm going to back it out and leave the NI open http://hg.mozilla.org/releases/l10n/mozilla-aurora/es-ES/rev/a06b594d6601 I'm still not sure if es-ES has switched to Pootle, but that commit just deletes a ton of strings.
Summary: [es-ES] Please remove mobile/searchplugins/list.txt.txt → [es-ES] Revert Pootle's commit
Assignee: rpmdisguise-otros → francesco.lodolo
Summary: [es-ES] Revert Pootle's commit → [es-ES] Revert Pootle's commit a06b594d6601 on /mobile
OK investigated this. Seems like we didn't have mobile locked down to prevent user contrubution on Spanish like we have it locked down on Firefox. A user contributed which triggered a manual push. Auto-pushes wouldn't have triggered as it prevents es landing. I don't have time to look at reverting this today. But would be happy if someone else could pick up the revert. I've made changes on Pootle to block any user contribution to es mobile/ which solves some of the problem. When auto-commits are back the balance should be solved in that it won't be able to commit.
(In reply to Dwayne Bailey from comment #4) > I don't have time to look at reverting this today. But would be happy if > someone else could pick up the revert. Revert has already been done (see comment 3). Closing this bug then, thanks.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Sorry for showing up so late to this. Certainly, we haven't moved to Pootle. I plan to switch from MozillaTranslator to a new Java tool that I'm writing in a near future, but it shouldn't trigger big changes and I will monitor it closely to avoid breaking anything. :-) I'll follow up about this in m.d.l10n-tools soon.
OK, I have a technical question about this bug. How should I deal with these changesets in l10n-central? I'm afraid of simply importing them in central following the usual procedure of hg pull -r default [aurora].
(In reply to Ricardo Palomares from comment #7) > OK, I have a technical question about this bug. How should I deal with these > changesets in l10n-central? I'm afraid of simply importing them in central > following the usual procedure of hg pull -r default [aurora]. It won't create any issue, because you'll pull both changesets (mess+backout). It's also easy to verify: * make a copy of the folder with your l10n-central clone * import from mozilla-aurora, merge and commit * replace the content of l10n-central (just merged) with the copy you made before merge, "hg status" should be empty In your case the only difference this be will changeset, because it's available only on mozilla-aurora, so it's expected to be missing in l10n-central before merge http://hg.mozilla.org/releases/l10n/mozilla-aurora/es-ES/rev/a34f10f89837
You need to log in before you can comment on or make changes to this bug.