in bug 488218, we used US-en hard coded strings. we need to localize these.
Attachment #373338 - Flags: review? → review?(gavin.sharp)
Comment on attachment 373338 [details] [diff] [review] patch v.1 >+geolocation.learnMore=Learn More... ... should this be using hellip?
can i just replace "..." with "…"
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
axel tells me that the localization note should be directly above the entity. i can fix that before I push
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Priority: -- → P2
Attachment #373349 - Flags: review? → review?(gavin.sharp)
Attachment #373349 - Flags: review?(gavin.sharp) → 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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
carrying forward gavin's r+
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 intl.properties 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 ...
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.
Follow up is bug 491739
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: http://mxr.mozilla.org/mozilla1.9.1/source/browser/components/nsBrowserGlue.js#1100
ah, right. pretty sure mike also wanted these. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f573430102e6
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 http://groups.google.com/group/mozilla.dev.l10n/browse_frm/thread/0f7ae76ae424e870#.
You need to log in before you can comment on or make changes to this bug.