Closed Bug 86248 Opened 23 years ago Closed 23 years ago

Drop-down search text in address bar not localizable

Categories

(Core :: Internationalization: Localization, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: karl, Assigned: yinglinxia)

References

Details

(Keywords: l12y)

Attachments

(4 files)

The drop-down search text in the address bar ("Search <searchengine> for <keywords>") is currently (2001-06-13 build) not localizable. It should be.
Keywords: l12y
QA Contact: andreasb → jonrubin
Reassigned to Amasri.
Assignee: rchen → amasri
Keywords: nsBranch
mass change, switching qa contact from jonrubin to ruixu. Re-assigning owner from amasri to mcarlson. Michele, please re-assign further.
Assignee: amasri → mcarlson
QA Contact: jonrubin → ruixu
Keywords: nsbranch-
removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.
Keywords: nsbranch
Blocks: 107067
Keywords: nsbranch-
ruixu - can you please take a look at this bug and give us more information including a screenshot?
Assignee: mcarlson → rchen
Steps to repro: 1. Launch browser. 2. Input some text into URL input box. 3. Observe the drop-down text. Please refer to the attachment.
Do you know where the string come from? -> pchen
Assignee: rchen → pchen
Hi, Tao and Frank, who is going to take care pchen's l12y bugs? I just made a patch above, wonder someone can take a look.
Hi, Don: Would you take a look? -thx
FYI. I also tested within Ja build, it works fine with Japanese.
1. Should we put the strings in its own properties file just like the rest of XUL files to relate them? 2. Or can we add one comment to indicate which source file using the strings?
Attached patch Updated patch (deleted) — Splinter Review
> 1. Should we put the strings in its own properties file... Not sure if it's necessary to make some new files for this one simple string. >2. Or can we add one comment to indicate which source file using the strings? Done.
->default assignee
Assignee: pchen → rchen
back to pchen. cc msanz.
Assignee: rchen → pchen
Keywords: nsbeta1
pchen is gone. -> hewitt
Assignee: pchen → hewitt
This bug is bad. Please triage it to nsbeta1+ and set mozilla 1.0 milestone. Please also review and sr the patch. Joe, if you need help, please let me know. Thanks.
*** Bug 111053 has been marked as a duplicate of this bug. ***
*** Bug 111053 has been marked as a duplicate of this bug. ***
please r and sr.
I will review it.
*** Bug 126666 has been marked as a duplicate of this bug. ***
Blocks: 126415
Attachment #66513 - Flags: review+
r=rchen, Joe, can you recommend sr?
Comment on attachment 66513 [details] [diff] [review] Updated patch 1. please align the <![CDATA section with the <field, don't indent it. 2. You shouldn't be search/replacing the %1 strings yourself. Use nsIStringBundle::formatStringFromName
Attachment #66513 - Flags: needs-work+
>2. You shouldn't be search/replacing the %1 strings yourself. Use > nsIStringBundle::formatStringFromName But can formatStringFromName deal with 2 substrings but may in different order of "%S"?. For example, in other languages, "Search Netscape for 'abc'" could be translated in different order like "For 'abc' search Netscape".
Please let me know if formatStringFromName has to be used here, I can make a localization notes in the properties file, to ask localizer DO NOT change the %S order in "Search %S for %S".
Joe, do you mind providing your patch? Ying and I just try to help and we would like to have this bug fixed asap. Please let us know. Thanks.
If it helps, I attached a patch to bug 126666 which uses formatSringFromName and re-uses a string with the same wording that we're using for context menus. see http://bugzilla.mozilla.org/attachment.cgi?id=71470&action=view for the attachment.
Reuse another string is not a good idea, for example, for other languages like Japanese, same string can be translated in different way, depends on where the string shows on the screen.
Hope this one makes everybody happy;-) Please understand this is critical for our l10n, we need to get it fixed asap. Need r and sr.
Comment on attachment 72083 [details] [diff] [review] Updated patch with hewitt input. sr=hewitt
Attachment #72083 - Flags: superreview+
nsbeta1+ per ADT triage team
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla1.0
Joe, do you mind I checkin the fix for Ying?
Comment on attachment 72083 [details] [diff] [review] Updated patch with hewitt input. a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #72083 - Flags: approval+
Checkin.
Assignee: hewitt → yxia
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Checkined for Mozilla tree. Will checkin NS tree, too.
Blocks: 129126
Checkin NS tree!
will verify with a localized build later.
Rui, you can verify it now. I just tested 02-03-07 build by modifying the file in language pack, the "Search for" shows as proper Japanese.
Ying, Can you let me know which file I should modify for this test?
Take a look the patch, you will see the file is "navigator.properties".
Tried modifying navigator.properties in the jar file, then started the browser, got crash every time, it crashed even if I only unzip and zip that jar file, so it might be better to wait for a localized build. Will verify later.
This has been working since it's been checked in for me and others in my local German build and German XPI Nightly Packs from http://www.kairo.at/mozilla/
Following Ray's document "Hardcoded String Verification and L12Y Test Procedure", checked this bug with 2002-03-11 trunk build, works fine on Win, Linux and Mac. Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: