CSS coverage: rename csscoverage.noMatch to reflect new content

RESOLVED FIXED in Firefox 32

Status

RESOLVED FIXED
5 years ago
6 months ago

People

(Reporter: flod, Assigned: jwalker)

Tracking

Trunk
Firefox 32

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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 ;-)
Summary: CSS coverage: rename csscoverage.noPreload to reflect new content → CSS coverage: rename csscoverage.noPreload and csscoverage.noMatch to reflect new content
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.
(Reporter)

Comment 3

5 years ago
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?
(Reporter)

Comment 5

5 years ago
(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
(Reporter)

Updated

5 years ago
Summary: CSS coverage: rename csscoverage.noPreload and csscoverage.noMatch to reflect new content → CSS coverage: rename csscoverage.noMatch to reflect new content
(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?
Created attachment 8430000 [details] [diff] [review]
l10nfix-1016820.patch

Also fixed - 2 localization notes that didn't match the strings they commented on.
Attachment #8430000 - Flags: review?(pbrosset)
Comment on attachment 8430000 [details] [diff] [review]
l10nfix-1016820.patch

Review of attachment 8430000 [details] [diff] [review]:
-----------------------------------------------------------------

looks good
Attachment #8430000 - Flags: review?(pbrosset) → review+
(Reporter)

Comment 10

5 years ago
(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/mozilla-central/rev/24325e3a3de5
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32

Updated

6 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.