Closed
Bug 128396
Opened 22 years ago
Closed 3 years ago
blank titlebar for cyrillic text when locale is specified
Categories
(Core :: Internationalization, defect, P4)
Tracking
()
RESOLVED
INACTIVE
Future
People
(Reporter: lesha37, Unassigned)
References
()
Details
(Keywords: intl, Whiteboard: needhelp)
Short story: When locale is set to "ru" produced with: localedef -f charmaps/KOI8-R -i locales/POSIX ru set with (bash syntax) export -n LC_ALL export LANG=ru Mozilla displays completely blank titlebars for Russian pages; without the locale specification, Russian characters are filled with question marks. With the locale specified, Mozilla should display the title bar in Russian (KOI8). Reproducibility: Always Long story: This was done on Linux 2.4.12 with XF 4.1, mozilla using 0.9.8 compiled from source, and also with the linux binary distro of the same. Initially, I was trying to make copy-paste to external apps not return question marks. I looked around, and determined that I needed to set my locale. After I set my locale ("ru"), compiled using: localedef -f charmaps/KOI8-R -i locales/POSIX ru set with (bash syntax) export -n LC_ALL export LANG=ru Mozilla indeed started to copy and paste correctly. However, there were two unpleasant side effects. Firstly, the fonts became slightly messed (the kerning on Yandex looked weird, for instance). Secondly, the title bars of all Russian pages became blank (this is on AfterStep). Further investigation of title bars: On WindowMaker, the Russian characters are simply missing from the titlebar. xwininfo returns no title on the Mozilla window. The calls to gtk_set_window_title and XChangeProperty in nsWindow::SetTitle both received correct parameters, however (more about correctness later). Upon restarting into AfterStep from WindowMaker, weird changes appear in the Moz titlebar: multiple instances of /1 and koi8. xwininfo still returns no title. Commenting out Ilya Konstantinov's change to SetTitle (XChangeProperty) has no effect on the behavior. On correctness: before I set the locale, I was able to make Mozilla behave 100% correctly with a hack: Change line 211 of nsUNIXCharset.cpp (0.9.8 version) from #if HAVE_NL_LANGINFO && defined(CODESET) nl_langinfo_codeset = nl_langinfo(CODESET); NS_ASSERTION(nl_langinfo_codeset, "cannot get nl_langinfo(CODESET)"); to (context omitted) nl_langinfo_codeset = "KOI8-R"; That way, copy-paste works, and titlebars are displayed fine (with actual Russian letters instead of question marks). The fonts are intact as well. Even more interestingly: if I name the above locale "nl" instead of "ru" (I'd guess this will work with any other latin-based locale as well), everything works just like with the hard-coded hack.
Comment 1•22 years ago
|
||
I can not reproduce it on linux RH7.2 when I login as Russian, the locale was "ru_RU.KOI8-R". There is no "ru" locale on my system. Reporter: Which linux system are you using?
Reporter | ||
Comment 2•22 years ago
|
||
Yuying Long: My system is a largely customized flavor of Slackware 7.1; The "ru" locale was created using a command (localedef -f charmaps/KOI8-R -i locales/POSIX ru) executed from /usr/share/i18n. I've also tried using ru_RU instead of a POSIX locale, and using the name "ru_RU.KOI8-R" instead of "ru". The result is the same. I have even tried some pre-packaged ru_RU.KOI8-R locale files from other distributions. If you post the associated files for your ru_RU.KOI8-R locale (LC_* from something like /usr/share/locale/ru_RU.KOI8-R), I can give that a try as well.
Comment 3•22 years ago
|
||
OK, I found the ru_RU locale under my /usr/share/i18n/locale. And I can reproduce the problem under lcoale "ru_RU". Confirm and cc shanjian, ftang.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•22 years ago
|
||
P4 future. If you have a patch to fix it , give it to me. Otherwise, I will delay Russian specific issue.
Status: NEW → ASSIGNED
Priority: -- → P4
Whiteboard: needhelp
Target Milestone: --- → Future
Comment 6•19 years ago
|
||
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Comment 7•19 years ago
|
||
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his fault not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 8•19 years ago
|
||
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be re-open. Spam is his fault not my own
Assignee: ftang → nobody
Status: REOPENED → NEW
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 9•3 years ago
|
||
This is verified to work today. Reopen if needed.
Status: NEW → RESOLVED
Closed: 19 years ago → 3 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•