Drop-down search text in address bar not localizable

VERIFIED FIXED in mozilla1.0

Status

()

VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: karl, Assigned: yinglinxia)

Tracking

({l12y})

Trunk
mozilla1.0
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
The drop-down search text in the address bar ("Search <searchengine> for
<keywords>") is currently (2001-06-13 build) not localizable. It should be.
(Reporter)

Updated

18 years ago
Keywords: l12y

Updated

18 years ago
QA Contact: andreasb → jonrubin

Comment 1

18 years ago
Reassigned to Amasri.
Assignee: rchen → amasri

Updated

18 years ago
Keywords: nsBranch

Comment 2

17 years ago
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

Updated

17 years ago
Keywords: nsbranch-

Comment 3

17 years ago
removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.
Keywords: nsbranch

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-

Comment 4

17 years ago
ruixu - can you please take a look at this bug and give us more information
including a screenshot?
Assignee: mcarlson → rchen

Comment 5

17 years ago
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.

Comment 6

17 years ago
Created attachment 56988 [details]
Drop-down search text in URL address bar

Comment 7

17 years ago
Do you know where the string come from?

-> pchen
Assignee: rchen → pchen
(Assignee)

Comment 9

17 years ago
Created attachment 66390 [details] [diff] [review]
A "try-out" patch to remove the hardcoded string from xml
(Assignee)

Comment 10

17 years ago
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.

Comment 11

17 years ago
Hi, Don:

Would you take a look? -thx
(Assignee)

Comment 12

17 years ago
FYI. I also tested within Ja build, it works fine with Japanese.

Comment 13

17 years ago
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?
(Assignee)

Comment 14

17 years ago
Created attachment 66513 [details] [diff] [review]
Updated patch

> 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.

Comment 15

17 years ago
->default assignee
Assignee: pchen → rchen

Comment 16

17 years ago
back to pchen. cc msanz.
Assignee: rchen → pchen
Keywords: nsbeta1

Comment 17

17 years ago
pchen is gone. -> hewitt
Assignee: pchen → hewitt

Comment 18

17 years ago
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.

Comment 19

17 years ago
*** Bug 111053 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
*** Bug 111053 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

17 years ago
please r and sr.

Comment 22

17 years ago
I will review it.

Comment 23

17 years ago
*** Bug 126666 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 126415

Updated

17 years ago
Attachment #66513 - Flags: review+

Comment 24

17 years ago
r=rchen, Joe, can you recommend sr?

Comment 25

17 years ago
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+
(Assignee)

Comment 26

17 years ago
>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".
(Assignee)

Comment 27

17 years ago
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".

Comment 28

17 years ago
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. 

Comment 29

17 years ago
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.
(Assignee)

Comment 30

17 years ago
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.
(Assignee)

Comment 31

17 years ago
Created attachment 72083 [details] [diff] [review]
Updated patch with hewitt input.

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 32

17 years ago
Comment on attachment 72083 [details] [diff] [review]
Updated patch with hewitt input.

sr=hewitt
Attachment #72083 - Flags: superreview+

Comment 33

17 years ago
nsbeta1+ per ADT triage team
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0

Comment 34

17 years ago
Joe, do you mind I checkin the fix for Ying?

Comment 35

17 years ago
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+

Comment 36

17 years ago
Checkin.
Assignee: hewitt → yxia

Comment 37

17 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 38

17 years ago
Checkined for Mozilla tree. Will checkin NS tree, too.
(Assignee)

Updated

17 years ago
Blocks: 129126

Comment 39

17 years ago
Checkin NS tree!

Comment 40

17 years ago
will verify with a localized build later.
(Assignee)

Comment 41

17 years ago
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.

Comment 42

17 years ago
Ying, Can you let me know which file I should modify for this test?
(Assignee)

Comment 43

17 years ago
Take a look the patch, you will see the file is "navigator.properties".

Comment 44

17 years ago
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.

Comment 45

17 years ago
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/

Comment 46

17 years ago
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.