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

Status: VERIFIED DUPLICATE of bug 39902

(SeaMonkey :: General, defect, P3)

Description

[Teruko Kobayashi]

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

[rchen]

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

Comment 2

[rchen]

Attachment: This is the Japanese editor.properties

Comment 3

[rchen]

Same problem happend at 

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

Comment 4

[Teruko Kobayashi]

Added jab1 in keywords.

Comment 5

[Teruko Kobayashi]

Clearing jab1 since this is not localization bug.

Comment 6

[Frank Tang]

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) 

Comment 7

[Peter Trudelle]

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

[bobj]

bug 31755 was duped to bug 31382, so updated dependency.

Comment 9

[Peter Trudelle]

Still don't know why this was assigned to me, giving back to ftang.

Comment 10

[Frank Tang]

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.

Comment 11

[Peter Trudelle]

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

Comment 12

[Frank Tang]

I think law is working on 31246. Maybe you should give this bug to him.

Comment 13

[Bill Law]

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.

Comment 14

[Kathleen :Brade]

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

[Kathleen :Brade]

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?

Comment 16

[Charles Manske]

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

[Charles Manske]

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.

Comment 18

[rchen]

Add nsbeta2 keyword.

Comment 19

[Katsuhiko Momoi]

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

Comment 20

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 21

[don]

Move to M18 target milestone.

Comment 22

[Bill Law]

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.

Comment 23

[msanz]

changing QA contact, Teruko, can you try and reproduce this bug? Thanks.

Comment 24

[rchen]

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

[bobj]

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

Comment 26

[rchen]

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

Comment 27

[Makoto Kato [:m_kato]]

??.  editor.properties isn't used.  This dialog is rewrriten to nsIFilePicker.
frank, dup of bug 39902??

Comment 28

[Makoto Kato [:m_kato]]

law, a patch already exists in bug 39902.
please dup to bug 39902.

Comment 29

[Bill Law]

Closing as dup of 39902, as instructed.

*** This bug has been marked as a duplicate of 39902 ***

Comment 30

[Matt Perry]

Verified duplicate.