The following two strings "Search" "Enter a search term:" are hardcoded in http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/gopher/src/nsGopherChannel.cpp#660
Moved from bugscape http://bugscape.netscape.com/show_bug.cgi?id=19944
Summary: Hardcoded string in Gopher search alert → Hardcoded strings in Gopher search alert
Carrying over keyword and status whiteboard marking, cc's to this bugzilla bug from bugscape. juraj: pls carry over your patch from bugscape to this bug, with sr=bryner. let's get this one fixed on the 1.0 branch asap for a major embedding customer.
Severity: normal → critical
Keywords: approval, edt1.0.2, mozilla1.0.2, nsbeta1+, topembed+
Priority: -- → P1
Whiteboard: [adt2] [ETA 09/14]
Target Milestone: --- → mozilla1.0.2
This fix will externalize 2 localizable strings as noted above. Cc'ing l10n folks. Pls add others as needed.
Comment on attachment 99170 [details] [diff] [review] corrected trunk patch transferring sr=bryner
Attachment #99170 - Flags: superreview+
ftang, roy could you r=?
Status: NEW → ASSIGNED
Why do you need to proxy this? The threading rules for necko mean that 'stuff' is always started from teh UI thread.
Look, I know very little about Necko - the code is straight out of the socket transport service. http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransportServic e.cpp#814 Bradley, did you put these strings in here? Can you help us with the patch? We need to land it on the trunk ASAP, the branch would have to follow very soon thereafter.
Yeah, I probably have blame for not localising this. I don't have time to test this, but if you replace the NS_WITH_PROXIED_SERVICE with do_getService directly, then the patch is fine.
I have concerns about Necko depends on intl. (see Makefile.in) I thought we had problem with this during xpinstall before. darin: I'm not very familiar about dependency structure of Necko; but is it ok to have gopher depends of intl?
hmmmm. I see jbetak's #8 comment and, indeed, necko is already depend on intl. Ignore my comment above.
Comment on attachment 99170 [details] [diff] [review] corrected trunk patch /r=yokoyama with do_getService() instead of NS_WITH_PROXIED_SERVICE
Attachment #99170 - Flags: review+
jbetak/tao:we got r & sr =, pls request drivers' approval for a trunk landing (if needed). we'd like to get this baked for a day before taking it to the 1.0 branch. thanks!
roy: the problem as far as i recall had to do with XPCOM depending on intl. it is ok for necko to depend on intl.
Created attachment 99403 [details] [diff] [review] patch v2 this will land momentarily
Attachment #99170 - Attachment is obsolete: true
Trunk patch has just landed. I'll keep this open for the pending branch fix.
Whiteboard: [adt2] [ETA 09/14] → [adt2] [trunk patch has landed, branch patch ETA 09/17]
Resolving as fixed per Comment #17 From email@example.com, so that QA can verify as fixed on tomorrow's trunk builds. We use keywords (i.e. edt1.02 and mozilla1.0.2) to manage 1.0 branch checkins. ji: pls verify this as fixed on tomorrow's trunk builds. thanks!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
edt1.0.2+ (per verbal from saari) approval for landing on the 1.0 branch, pending Drivers' approval. Pls land time asap, the replace "mozilla1.0.2+" with "fixed1.0.2". thanks!
Keywords: edt1.0.2 → edt1.0.2+
Comment on attachment 99403 [details] [diff] [review] patch v2 firstname.lastname@example.org for 1.0 branch. Please change mozilla1.0.2+ to fixed1.0.2 when checked in. JaimeJr, please be more clear in your comments; it sounded like you were giving the a= for this bug.
Attachment #99403 - Flags: approval+
Comment on attachment 99551 [details] [diff] [review] branch patch carrying over r=yokoyama sr=bryner a=rjesup
branch patch has landed
Keywords: mozilla1.0.2 → fixed1.0.2
Whiteboard: [adt2] [trunk patch has landed, branch patch ETA 09/17] → [adt2] [trunk patch has landed, branch patch has landed]
Verified as fixed with 09/17 trunk build. Replaced the two new strings in necko.properties with pseudo localized strings, the localized strings appear in the search dialog.
Status: RESOLVED → VERIFIED
ji, just a friendly heads-up: we'll need to verify this in a 1.0 branch build or in Moz1.0.2 as well
I'll verify this on branch build tomorrow.
Verified as fixed on 09/18 branch build.
Keywords: fixed1.0.2 → verified1.0.2
You need to log in before you can comment on or make changes to this bug.