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

VERIFIED DUPLICATE of bug 39902

Status

defect
P3
normal
VERIFIED DUPLICATE of bug 39902
20 years ago
15 years ago

People

(Reporter: teruko, Assigned: law)

Tracking

Trunk
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 attachment)

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.
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
Same problem happend at 

1. Open Composer
2. Select menu Insert | Image to open Image Properties dialog
3. Select Choose File.. button 
Blocks: 12394
Added jab1 in keywords.
Keywords: jab1
Clearing jab1 since this is not localization bug.
Keywords: jab1
Status: NEW → ASSIGNED
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
Frank, why did you assign this to me?  Isn't it just a tracking bug, with all of 
the work in the dependencies?  
bug 31755 was duped to bug 31382, so updated dependency.
Depends on: 31382
Still don't know why this was assigned to me, giving back to ftang.
Assignee: trudelle → ftang
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
You've identified two parts to this bug, both of which have their own bug.  
What is *this* bug about?
I think law is working on 31246. Maybe you should give this bug to him.
Assignee: trudelle → 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.
Assignee: law → brade
Component: Internationalization → Editor
QA Contact: teruko → sujay
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!
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
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?
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
Blocks: 14744
Add nsbeta2 keyword.
Keywords: nsbeta2
Target Milestone: --- → M17
*** Bug 31621 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Move to M18 target milestone.
Target Milestone: M17 → M18
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
changing QA contact, Teruko, can you try and reproduce this bug? Thanks.
QA Contact: sujay → teruko
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. 
Just to confirm, I assume you meant escaped Unicode when you wrote
"Japanese unicode strings" in previous comment.
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.
Closing as dup of 39902, as instructed.

*** This bug has been marked as a duplicate of 39902 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Verified duplicate.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.