Joe, either you temporary disable the localization of this project as Paul suggested in another bug or you need to follow the rules we have in place about string changes https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_best_practices#Changing_existing_strings -<!ENTITY csscoverage.noPreload "All rules are inlined. We don't have suggestions about how to improve performance on this page right now."> +<!ENTITY csscoverage.noPreload "All rules are inlined."> This one needs to be renamed.

Also -<!ENTITY csscoverage.noMatch "The following selectors did not match any elements that we saw during the test so it's possible they can be safely removed."> +<!ENTITY csscoverage.noMatch "No matches found for the following rules:"> http://hg.mozilla.org/mozilla-central/diff/f965b7cef97f/toolkit/locales/en-US/chrome/global/devtools/csscoverage.dtd To clarify: to discover these, I need to go through every single commit in http://hg.mozilla.org/mozilla-central/log?rev=locales%2Fen-US So these bugs make both of us unhappy ;-)

Ah, sorry about that. I wasn't aware that we could disable localization I think we should do that more for things that have just landed. How does that work? Chrome devtools don't do any localization at all ever. I don't think they've got it right, but on the other hand we are concerned about up-to-date translations for features that are only on Nightly and turned off so people can't see them until they're ready. I think we need a way to get things through the stage where churn is likely and hard to track before localization starts.

Let me clarify what I meant: devtools must remain localizable, and that must happen on mozilla-central, so that we can check (and fix) the strings before they move to mozilla-aurora, which is string frozen. Some languages, even if they're a minority (count mine in), consider this fundamental. We can't ship things in English in Firefox. What I meant in comment 0 is: if you're heavily developing this feature, and you don't plan to enable it in this cycle, you could leave l10n outside for a while like app manager is doing (bug 1011464). But localization needs to be re-enabled at some point.

To clarify comment 2: There are many reasons for people to use the pref-system to hide features when they land on central, among them that the code is at risk of bit-rotting, also that we're unsure of the UI and need more feedback. For both of these cases these 2 things are true: * We pref it off so we're not shipping * Strings are much more likely to change than normal I think we agree for these things that we should not be doing any localization. I see how it's working in bug 1011464, but I wonder if there isn't an easier solution like adding to a string comment "DO NOT LOCALIZE" or something. Obviously this comment would be removed prior to preffing-on. Could that work?

(In reply to Joe Walker [:jwalker] from comment #4) > I think we agree for these things that we should not be doing any > localization. I see how it's working in bug 1011464, but I wonder if there > isn't an easier solution like adding to a string comment "DO NOT LOCALIZE" > or something. Obviously this comment would be removed prior to preffing-on. > Could that work? No, because tools won't parse that kind of comment, and strings will be a) marked as missing, b) exposed to localization tools for translation. To be clear: I'm perfectly fine in changing strings twice a week for devtools, that's the price I pay for working on central, as long as IDs change as well.

(In reply to Francesco Lodolo [:flod] from comment #0) > Joe, either you temporary disable the localization of this project as Paul > suggested in another bug or you need to follow the rules we have in place > about string changes > https://developer.mozilla.org/en-US/docs/Mozilla/Localization/ > Localization_best_practices#Changing_existing_strings > > -<!ENTITY csscoverage.noPreload "All rules are inlined. We don't have > suggestions about how to improve performance on this page right now."> > +<!ENTITY csscoverage.noPreload "All rules are inlined."> > > This one needs to be renamed. This one is already fixed here: https://hg.mozilla.org/integration/fx-team/rev/aa06a0c23d46

(In reply to Francesco Lodolo [:flod] from comment #5) > (In reply to Joe Walker [:jwalker] from comment #4) > > I think we agree for these things that we should not be doing any > > localization. I see how it's working in bug 1011464, but I wonder if there > > isn't an easier solution like adding to a string comment "DO NOT LOCALIZE" > > or something. Obviously this comment would be removed prior to preffing-on. > > Could that work? > > No, because tools won't parse that kind of comment, and strings will be a) > marked as missing, b) exposed to localization tools for translation. > > To be clear: I'm perfectly fine in changing strings twice a week for > devtools, that's the price I pay for working on central, as long as IDs > change as well. By string comment I mean something like this. <!-- LOCALIZATION NOTE (csscoverage.optimize): DO NOT LOCALIZE YET This is the heading for the CSS optimization part of the report --> <!ENTITY csscoverage.optimize.header "Optimizable Pages"> I guess all localizers would see this string wouldn't they?

Also fixed - 2 localization notes that didn't match the strings they commented on.

Comment on attachment 8430000 [details] [diff] [review] l10nfix-1016820.patch Review of attachment 8430000 [details] [diff] [review]: ----------------------------------------------------------------- looks good

(In reply to Joe Walker [:jwalker] from comment #7) > I guess all localizers would see this string wouldn't they? Not necessarily. Also, it would create more confusion than clarity: why am I seeing a string that I'm not supposed to localize yet? And it wouldn't save us from having to rename the ID every time (no way to know if someone translated it already, and the content is updated).

https://hg.mozilla.org/integration/fx-team/rev/24325e3a3de5 https://tbpl.mozilla.org/?tree=Fx-Team&rev=24325e3a3de5