Problem with localization in file open/save dialogs

VERIFIED FIXED

Status

()

VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: DmiG, Assigned: mkaply)

Tracking

({intl})

Trunk
All
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:0.9.9) Gecko/20020311
BuildID:    2002031114

In file open/save dialogs, there are some strings (file type, may be something
else), Mozilla get from locale .jar, thoose strings are in unicode, and OS/2
doesn't work with unicode directly, so unicode text must be translated to
current system codepage.

Reproducible: Always
Steps to Reproduce:
1. Install any non-latin localization package (I use russian).
2. Select that language.
3. Open any file dialog.

Actual Results:  Then in file open/save dialogs you can see unicode strings with
lost second byte (file type field).

Expected Results:  Translate file type strings from unicode, to current system
codepage.
Michael, who should get this?  This sounds like a problem in nsFilePicker.cpp...
(Assignee)

Comment 2

17 years ago
I'll take it for now.

I'm not convinced, though - we have shipped many translated browsers 
(Including Japanese) without this problem.
Assignee: rchen → mkaply
(Assignee)

Comment 3

17 years ago
I humbly eat my words. I don't know how we missed this in translation.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 4

17 years ago
It sounds like a dup of bug 135854 which is i18n problem.

Reporter: can you try a file name with a space, e.g. "A B" see if you have same
problem? and could you provide a screen shot?  thanks!

(Assignee)

Comment 5

17 years ago
I think the issue here is Os/2 specific - that we are not converting the file 
type strings to a native charset before using them. I am investigating.
(Assignee)

Comment 6

17 years ago
Created attachment 80455 [details] [diff] [review]
Fix for problem

We need to call WideCharToMultibyte to convert the passed in Unicode strings
before using them.
Comment on attachment 80455 [details] [diff] [review]
Fix for problem

r=pedemont
Attachment #80455 - Flags: review+
(Assignee)

Comment 8

17 years ago
Comment on attachment 80455 [details] [diff] [review]
Fix for problem

sr=blizzard (platform specific code)
Attachment #80455 - Flags: superreview+
(Assignee)

Comment 9

17 years ago
Checked into trunk. Still need to go on branch.

Comment 10

17 years ago
Reporter: could you please verify it on latest trunk build with OS/2? thanks!
Comment on attachment 80455 [details] [diff] [review]
Fix for problem

a=roc+moz for branch
Attachment #80455 - Flags: approval+
(Assignee)

Comment 12

17 years ago
Fix checked into brancj
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 13

17 years ago
Reporter: could you please verify it using latest build on OS/2? thanks!

Updated

17 years ago
Keywords: fixed1.0.0

Comment 14

17 years ago
adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it
was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify
the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword
with verified1.0.0.

Comment 15

17 years ago
I don't see the problem here, mark as verified.

Please reopen if still see the problem.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
You need to log in before you can comment on or make changes to this bug.