Japanese file types do not displayed correctly in Open HTML File dialog

VERIFIED DUPLICATE of bug 39902

Status

SeaMonkey
General
P3
normal
VERIFIED DUPLICATE of bug 39902
18 years ago
14 years ago

People

(Reporter: Teruko Kobayashi, Assigned: Bill Law)

Tracking

Trunk
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
When you open the Open HTML File dialog, the JA translation of File types in the Open HTML File dialog are
displayed as "....".

Steps of reproduce
1. Open Composer
2. Select menu Insert | Link to open Link Properties dialog
3. Select Choose File.. button 

At the buttom of the Open HTML File dialog, the JA file types for "HTML Files", "Text Files", and "All Files" are displayed
as "......"

Tested 2000030709 Win32 JA build.

Comment 1

18 years ago
Reassigned to Ftang.

The data file is at chrome\editor\editor.properties:
HTMLFiles=HTML \u30d5\u30a1\u30a4\u30eb
IMGFiles=\u753b\u50cf\u30d5\u30a1\u30a4\u30eb
TextFiles=\u30c6\u30ad\u30b9\u30c8 \u30d5\u30a1\u30a4\u30eb
AllFiles=\u3059\u3079\u3066\u306e\u30d5\u30a1\u30a4\u30eb
Assignee: rchen → ftang
Component: Localization → Internationalization
Summary: Japanese file types do not displayed correctly in Open HTML File dialog → Japanese file types do not displayed correctly in Open HTML File dialog

Comment 2

18 years ago
Created attachment 6392 [details]
This is the Japanese editor.properties

Comment 3

18 years ago
Same problem happend at 

1. Open Composer
2. Select menu Insert | Image to open Image Properties dialog
3. Select Choose File.. button 

Updated

18 years ago
Blocks: 12394
(Reporter)

Comment 4

18 years ago
Added jab1 in keywords.
Keywords: jab1
(Reporter)

Comment 5

18 years ago
Clearing jab1 since this is not localization bug.
Keywords: jab1

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 6

18 years ago
There are several part of the problem: 
1. bug 31246 prevent passing Unicode data as inExtraFilterTitle, in order to fix 
that, we need to make sure the also need to fix 
nsFileSpecWithUIImpl::SetFileWidgetFilterList (see 31754)
2. currently, there are a lot of hard code string in 
nsFileSpecWithUIImpl::SetFileWidgetFilterList. These string have to be 
exteranalized so we can localized them. (see bug 31755) 
Assignee: ftang → trudelle
Blocks: 31752
Status: ASSIGNED → NEW
Depends on: 31246, 31754, 31755

Comment 7

18 years ago
Frank, why did you assign this to me?  Isn't it just a tracking bug, with all of 
the work in the dependencies?  

Comment 8

18 years ago
bug 31755 was duped to bug 31382, so updated dependency.
Depends on: 31382

Comment 9

18 years ago
Still don't know why this was assigned to me, giving back to ftang.
Assignee: trudelle → ftang

Comment 10

18 years ago
This is not a tracking bug. This is a real bug. We found several sub 
problems with it and I add them to the depends on list. I think you should 
assign this to someone in your group to fix them all.
Assignee: ftang → trudelle

Comment 11

18 years ago
You've identified two parts to this bug, both of which have their own bug.  
What is *this* bug about?

Comment 12

18 years ago
I think law is working on 31246. Maybe you should give this bug to him.
Assignee: trudelle → law
(Assignee)

Comment 13

18 years ago
Well I don't think I should have this either.  This seems to be referring to 
.properties files specific to Composer so I'm resetting the component to 
"Editor" and reassigning to that component's owner.
Assignee: law → brade
Component: Internationalization → Editor
QA Contact: teruko → sujay

Comment 14

18 years ago
Teruko--can you check if this bug also happens in the following places:
 * from the browser, choosing Open File...
 * from Composer, choosing Open File...
 * from Composer's image dialog (choose file button)

Thanks!

Comment 15

18 years ago
reassign this to Charley; he may be able to figure out what's special about link 
dialog (if indeed that is the problem).

Teruko--also, can you reproduce this on other platforms or just Windows?
Assignee: brade → cmanske

Comment 16

18 years ago
All open file dialogs from any dialog or the File menu use the same method
in nsEditorShell.cpp: "OpenLocalFile()". There's no need to check different 
dialogs -- they will all work or not. 
I don't think there is no separate Composer bug here. Looking at the dependent 
bugs that Frank added, they are the source of the problem. We are putting the 
appropriate strings (e.g. "HTML Files") in the editor.properties as we should, 
correct? 
Isn't the problem that the "common dialog" code is not converting the 
unichar version of the translated strings into the appropriate encoding for the 
dialog box?

Comment 17

18 years ago
Open file is now done entirely within Java Script code using nsIFilePicker
interface. If there are any problems communicating from this code to the 
OS-specific dialogs, then the problem lies in that code for all modules.
I think Bill Law handles the Windows common dialog code.
Assignee: cmanske → law
Component: Editor → Browser-General

Updated

18 years ago
Blocks: 14744

Comment 18

18 years ago
Add nsbeta2 keyword.
Keywords: nsbeta2
Target Milestone: --- → M17

Comment 19

18 years ago
*** Bug 31621 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]

Comment 21

18 years ago
Move to M18 target milestone.
Target Milestone: M17 → M18
(Assignee)

Comment 22

18 years ago
Can somebody verify that this problem still exists?  Changes were made to use a
differnt interface to the platform file picker dialog and that interface does
support Unicode.  I don't know if the platform dialog (or the code that
interfaces with it) do the right thing to ensure that the unicode appears properly.

If not, then the problem lies in mozilla/widget/src/windows/nsFilePicker.cpp.

If that code is broken, I would appreciate guidance on how to converse with the
platform file dialog so that Unicode strings appear properly.
Status: NEW → ASSIGNED

Comment 23

18 years ago
changing QA contact, Teruko, can you try and reproduce this bug? Thanks.
QA Contact: sujay → teruko

Comment 24

18 years ago
I think the data strings have moved to the file global\filepicker.properties. 

After I replaced with Japanese unicode strings, they appeared as "_______" in my 
Japanese NT with today's 0526 build. 

Comment 25

18 years ago
Just to confirm, I assume you meant escaped Unicode when you wrote
"Japanese unicode strings" in previous comment.

Comment 26

18 years ago
Yes, that's what I ment. Precisely, they are:
HTMLFiles=HTML \u30d5\u30a1\u30a4\u30eb
IMGFiles=\u753b\u50cf\u30d5\u30a1\u30a4\u30eb
TextFiles=\u30c6\u30ad\u30b9\u30c8 \u30d5\u30a1\u30a4\u30eb
AllFiles=\u3059\u3079\u3066\u306e\u30d5\u30a1\u30a4\u30eb
??.  editor.properties isn't used.  This dialog is rewrriten to nsIFilePicker.
frank, dup of bug 39902??
law, a patch already exists in bug 39902.
please dup to bug 39902.
(Assignee)

Comment 29

18 years ago
Closing as dup of 39902, as instructed.

*** This bug has been marked as a duplicate of 39902 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 30

18 years ago
Verified duplicate.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.