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
Added jab1 in keywords.
Clearing jab1 since this is not localization bug.
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)
Frank, why did you assign this to me? Isn't it just a tracking bug, with all of the work in the dependencies?
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
Add nsbeta2 keyword.
Target Milestone: --- → M17
*** Bug 31621 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar for beta2 fix.
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??
Closing as dup of 39902, as instructed. *** This bug has been marked as a duplicate of 39902 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.