Closed Bug 61676 Opened 24 years ago Closed 23 years ago

Browser never shows cyrillic and hebrew characters on Title Bar

Categories

(Core :: Internationalization, defect, P3)

x86
All
defect

Tracking

()

VERIFIED DUPLICATE of bug 9449
Future

People

(Reporter: lilac538, Assigned: ftang)

References

()

Details

(Keywords: intl)

Mozilla and Netscape always show page title on title bar.
Former Communicator shows cyrillic letters correctly, if
font  for any window title in OS or current window manager
set to cyrillic (same with hebrew).Unfortunately, in case
with Milestone18(I have now Build 2000091312) and Netscape6
title font looks like ????.???(Windows) or ......./...(Linux)
I say again,old Communicator does it right.
Target Milestone: --- → M18
Reassigned to ftang.
Assignee: rchen → ftang
Component: Localization → Internationalization
I am seeing this.
Platform: PC
OS: Windows 98
Mozilla Build #:2000121204 M18 Trunk

Marking as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
the window title is platform specific. I believe it currently can show those
character if they can be encoded into the locale encoding.
Reassign this to hyatt since he mention that he may have a way to hack the
window title. I am not sure how important to fix this now although we did
received a lot of this complains.
Assignee: ftang → hyatt
If the locale cannot display the title could we
transliterate?
Changed QA contact to andreasb@netscape.com for now.
QA Contact: teruko → andreasb
reassigning back to ftang, Hyatt can't take this on, no current plans for xp
titlebar.
Assignee: hyatt → ftang
Target Milestone: M18 → ---
Does your locale set to cyrillic locale ?
Adding keyword intl.
Keywords: intl
Just a quick note to add arabic to languages with wrong title.
Platform: PC
OS: Windows 2000
Build: 2001030505

URLs to test:
http://www.ayna.com/ (windows-1256, shows ????)
http://www.almosmem.com/otb9/ (warning !! Also crashes Mozilla, shows ??? in
title bar)
Status: NEW → ASSIGNED
mark it as future
Target Milestone: --- → Future
Reporter:
Isn't this a duplicate of bug 9449?
The reason you were able to see titles in Cyrillic
with the font for Windows title to one for Cyrillic
in NS 4.x is, in a sense, NS 4.x is "broken".
NS 4.x doesn't care whether what has to go into Windows title
is Cyrillic in a locale-dependent legacy encoding or French in
another locale-dependent legacy encoding(ISO-8859-1). It just *blindly*
hands over what it has to the Window-Manager(in Unix/X11,
Finder in MacOS, ??? in MS-Windows) regardless of the encoding 
of the string to display and the encoding of window manager(Finder, ???).
Therefore, just setting the font to use for WIndows-title display 
works for 1-byte encodings, but this wouldn't help for multi-byte encodings,
I guess

On the other hand, Mozilla/NS6 checks whether the encoding of the window
manager can display the string before handing it over to the window manager.
If not, it converts characters not displayable to question marks.

This is a generic problem across the platform.

One more note: Your linux problem is a bit different. As Frank suspected,
you must have the incorrect locale setting for Russian. You have to make
sure that BOTH your Window manager and Mozilla are running in the identical
Russian Locale and that your Window manager is *properly* I18Nized so
that it can understand and abide by X11 ICCCM (which Mozilla as well as NS 4.x
is compliant to). With these two things in place, you would not have
any problem as long as the locale of your WIndow manager can support 
display of the string in question (bug 9449 is for the case where this
is not the case). My suspicision is that your window manager is NOT
ICCCM compliant and kind of hacked to display "raw" string in locale-dependent
cyrillic encoding.  
You seem to imply that everybody that needs to read russian runs all OS in
Russian locale. This is plain wrong. I do not want Russian locale, I just want
to read Russian. These two things are different. I do not want Russian menus, I
do not want Russian dates, I do not want Russian ctypes. I just want to be able
to go to www.yandex.ru and see Russian there. 
That is to say, not everybody that needs to see Russian wants Russian locale. In
fact, there are a thousands of people that do not want any Russian locale but do
want Russian (including Russian window titles for Russian pages). I do not know
if there's any real solution to this problem redagrding to window manager title,
especially from Mozilla side (I suspect short of rewriting WM to support Unicode
not much can be done), but one should be aware of that and not just tell
everybody "set your locale to Russian" - it doesn't help.
And moreover, if old Netscape did it "right" - on the point of the user -
probably it is worth to look back to how it did this, because user doesn't
really care if it's theoretically correct, just does it work or not.
Changing QA contact to marina for now.
QA Contact: andreasb → marina
re-assigning QA contact
QA Contact: marina → ylong
*** Bug 92045 has been marked as a duplicate of this bug. ***
On X11 window managers which support _NET_WM_NAME and Unicode titles (such as kwin), this is already fixed (bug 9449).
Does this have anything to do with the fact that Mozilla 0.9.2 breaks off titles
that contain a high ASCII character instead of an entity (like é ) ?
If that is a separate bug, is it filed somewhere already?
The problem also exist on Red Hat 7.1/kernel 2.4.4 plus KDE 2.1.1 (english
locale but cyrillic support is installed) and Mozilla 0.9.3 (build 2001080104). 
Also I have to say that I heard a lot of complaints about this problem. Probably
it's a good idea to change the priority/severity of this bug because otherwise
Mozilla is unusable on non-English sites.
Upgrade to KDE 2.2, which contains the fixed netwm class. (if we wouldn't
trigger it, someone else would)

*** This bug has been marked as a duplicate of 9449 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Mark it as verified dup, please re-open if disagree.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.