Closed
Bug 31288
Opened 25 years ago
Closed 25 years ago
Japanese file types do not displayed correctly in Open HTML File dialog
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
M18
People
(Reporter: teruko, Assigned: law)
References
Details
(Whiteboard: [nsbeta2+])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 6•25 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)
Comment 7•25 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?
Depends on: 31382
Comment 9•25 years ago
|
||
Still don't know why this was assigned to me, giving back to ftang.
Assignee: trudelle → ftang
Comment 10•25 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•25 years ago
|
||
You've identified two parts to this bug, both of which have their own bug.
What is *this* bug about?
Comment 12•25 years ago
|
||
I think law is working on 31246. Maybe you should give this bug to him.
Assignee: trudelle → law
Assignee | ||
Comment 13•25 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•25 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•25 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•25 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•25 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
Comment 19•25 years ago
|
||
*** Bug 31621 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•25 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•25 years ago
|
||
changing QA contact, Teruko, can you try and reproduce this bug? Thanks.
QA Contact: sujay → teruko
Comment 24•25 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•25 years ago
|
||
Just to confirm, I assume you meant escaped Unicode when you wrote
"Japanese unicode strings" in previous comment.
Comment 26•25 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
Comment 27•25 years ago
|
||
??. editor.properties isn't used. This dialog is rewrriten to nsIFilePicker.
frank, dup of bug 39902??
Comment 28•25 years ago
|
||
Assignee | ||
Comment 29•25 years ago
|
||
Closing as dup of 39902, as instructed.
*** This bug has been marked as a duplicate of 39902 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 30•25 years ago
|
||
Verified duplicate.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•