Closed Bug 488574 Opened 14 years ago Closed 14 years ago

remove hardcoded english strings caused by bug 488218


(Firefox :: General, defect, P2)






(Reporter: dougt, Assigned: dougt)


(Keywords: fixed1.9.1, late-l10n, Whiteboard: [geo])


(1 file, 2 obsolete files)

in bug 488218, we used US-en hard coded strings.  we need to localize these.
Attached patch patch v.1 (obsolete) — Splinter Review
Attachment #373338 - Flags: review?
Flags: blocking-firefox3.5?
Attachment #373338 - Flags: review? → review?(
Comment on attachment 373338 [details] [diff] [review]
patch v.1

>+geolocation.learnMore=Learn More...

... should this be using hellip?
can i just replace "..." with "…"
Attached patch patch v.2 (obsolete) — Splinter Review
Attachment #373338 - Attachment is obsolete: true
Attachment #373349 - Flags: review?
Attachment #373338 - Flags: review?(
axel tells me that the localization note should be directly above the entity.  i can fix that before I push
Whiteboard: [geo]
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Keywords: late-l10n
Priority: -- → P2
Attachment #373349 - Flags: review? → review?(
Attachment #373349 - Flags: review?( → review+
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.
Closed: 14 years ago
Resolution: --- → FIXED
Attached patch inclusive patchSplinter Review
carrying forward gavin's r+
Attachment #373349 - Attachment is obsolete: true
Attachment #373660 - Flags: review+
Attachment #373660 - Flags: approval1.9.1?
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...
Yes, it should be "if". The existing comments in also have this problem.
Whiteboard: [geo] → [geo][will approve after b4 cutoff]
Comment on attachment 373660 [details] [diff] [review]
inclusive patch

We're actually gonna change some strings, I'll come back around to specify ...
Attachment #373660 - Flags: ui-review-
Attachment #373660 - Flags: approval1.9.1?
Attachment #373660 - Flags: approval1.9.1-
beltzner, lets open up a new bug for that work.
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 on attachment 373660 [details] [diff] [review]
inclusive patch

OK, I'll file the followup to change the strings.
Attachment #373660 - Flags: ui-review-
Attachment #373660 - Flags: approval1.9.1-
Attachment #373660 - Flags: approval1.9.1+
Please land this on branch.
Whiteboard: [geo][will approve after b4 cutoff] → [geo]
Those are different strings, as far as I can see. nsBrowserGlue.js still has the hardcoded string:
ah, right.  pretty sure mike also wanted these.
Keywords: fixed1.9.1
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?
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.
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.
(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?
Of course. Frankly, I don't know where I had to pick you up in explaining why.
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?
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
You need to log in before you can comment on or make changes to this bug.