488574 - remove hardcoded english strings caused by bug 488218

Status: RESOLVED FIXED

(Firefox :: General, defect, P2)

Description

[Doug Turner (:dougt)]

in bug 488218, we used US-en hard coded strings.  we need to localize these.

Comment 1

[Doug Turner (:dougt)]

Attachment: patch v.1

Comment 2

[Axel Hecht [:Pike]]

Comment on attachment 373338 [details] [diff] [review]
patch v.1

>+geolocation.learnMore=Learn More...

... should this be using hellip?

Comment 3

[Doug Turner (:dougt)]

can i just replace "..." with "…"

Comment 4

[Axel Hecht [:Pike]]

Sadly not, I suggest copy'n'paste from http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global-platform/win/intl.properties#5

Comment 5

[Doug Turner (:dougt)]

Attachment: patch v.2

Comment 6

[Doug Turner (:dougt)]

axel tells me that the localization note should be directly above the entity.  i can fix that before I push

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 373349 [details] [diff] [review]
patch v.2

You forgot the nsBrowserGlue changes in this diff, but r=me assuming they're the same as in attachment 373338 [details] [diff] [review], and with the l10n note moved per Axel.

Comment 8

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/be9560b1ed35

Comment 9

[Doug Turner (:dougt)]

Attachment: inclusive patch

carrying forward gavin's r+

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 373660 [details] [diff] [review]
inclusive patch

>+# LOCALIZATION NOTE (geolocation.learnMore): Use the unicode ellipsis char, \u2026,
>+# or use "..." unless \u2026 doesn't suit traditions in your locale.

Shouldn't this be "if" instead of "unless"?

As far as I understand the tree rules, this doesn't need approval after the beta freeze, since it's blocking...

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Yes, it should be "if". The existing comments in intl.properties also have this problem.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 373660 [details] [diff] [review]
inclusive patch

We're actually gonna change some strings, I'll come back around to specify ...

Comment 13

[Doug Turner (:dougt)]

beltzner, lets open up a new bug for that work.

Comment 14

[Axel Hecht [:Pike]]

Beltzner, Doug commented to possibly fork the string changes to a different bug, but you're not on CC so you probably didn't get that request.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 373660 [details] [diff] [review]
inclusive patch

OK, I'll file the followup to change the strings.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Follow up is bug 491739

Comment 17

[Dão Gottwald [:dao]]

Please land this on branch.

Comment 18

[Doug Turner (:dougt)]

this landed in bug 491739:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/78d6f3d51d82

Comment 19

[Dão Gottwald [:dao]]

Those are different strings, as far as I can see. nsBrowserGlue.js still has the hardcoded string:
http://mxr.mozilla.org/mozilla1.9.1/source/browser/components/nsBrowserGlue.js#1100

Comment 20

[Doug Turner (:dougt)]

ah, right.  pretty sure mike also wanted these.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f573430102e6

Comment 21

[Doug Turner (:dougt)]

fwiw, the only string difference between 1.9.1 and mc related to geolocation is the access key for the "remember this decision":

checkbox.setAttribute("accesskey", browserBundle.GetStringFromName("geolocation.remember.accesskey"));

gavin, do we want to ask for another localization change here?

Comment 22

[:Gavin Sharp [email: [e-mail]]]

If we've already made changes for this milestone, making one more probably won't hurt. On its own, the accesskey functionality is probably not worth the effort.

Comment 23

[Axel Hecht [:Pike]]

Adding one more string will make us slip the RC1 schedule now, I don't think that's acceptible. Making this change after RC1 will delay whichever RC would come after that, not sure if we're willing to take that either.

Comment 24

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #23)
> Adding one more string will make us slip the RC1 schedule now

One additional string on top of the two we've already added will make us slip RC1?

Comment 25

[Axel Hecht [:Pike]]

Of course. Frankly, I don't know where I had to pick you up in explaining why.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

Just to be clear, I meant "the two we've already added for this milestone". Doug pushed two string additions on the 15th. Now it's the 17th, and we're talking about potentially adding one more. Are you saying that localizers have already all updated their locales to add the 2 strings and gone through signoff, so adding one more will force them to go through another round?

Comment 27

[Axel Hecht [:Pike]]

Yes. Code freeze is supposed to be on Wednesday, and the usual concept is to have a l10n freeze at least over the weekend, with opt-in thread open. Which is http://groups.google.com/group/mozilla.dev.l10n/browse_frm/thread/0f7ae76ae424e870#.