From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686) Description of problem: When doing the fresh installation with kde, it does not show up all translations in some of the menus (tested with KR and JP) Version-Release number of selected component (if applicable): kdebase-2.2-9 How reproducible: Always Steps to Reproduce: 1. Install re0828.2 with KR or JP 2. run kde 3. open main menu 4. opps some of the translations is gone (ie. displays in english) Actual Results: some of the translation is gone like in main menu or kcontrol(ie. displays in english) Expected Results: shows all the translations Additional info: o happens in re0829 too - When you try to do: # rpm -e ttfonts-{ko,ja} # rpm -Uvh ttfonts-{ko,ja} - restart kde - the translations will come back o not working ideas like: restart xfs xset fp rehash restart X
Does this work with kdebase-2.2-10 for you?
kdebase-2.2-10 doesn't fix the problem for Japanese on my desktop.
Does it work if you rm -rf .kde after installing 2.2-10? The problem might have been caused by kcontrol writing bad charset information to your ~/.kde/share/config/* files.
rm -rf ~/.k* ~/.D* startkde but it won't fix.
Created attachment 30875 [details] This is default Korean desktop. (Ugly!)
What does chkfontpath --list say?
I have similar experience. It is possible that the locale is not ko_KR.eucKR. KDE will automatically changed all the font configs to first available font in the font list (ie. batang for KR). For the actual problem, I am still looking into it - will let you all know the updates.
Tested throughly on kde - Was trying to back-track the version of kdebase and kdelibs. Results: Installed re0831.0 (kde{base,lib}-2.2-9), jp locale Login as root After kpersonalize, restart X Some menu entries are in English Installed with kde{base,lib}-2.2-9}, rm -rf .kde, restart X Same Installed with 2.2-7, ..... Same Installed with 2.2-6, ..... After restart X, the menus works fine. Reinstall with 2.2-7, ..... Some menu entries changed back to English Therefore it's possible the changes from 2.2-6 to 2.2-7 effects. However I was trying to track down the changes, the only changes that I have found is exporting $KDEDIR using /etc/profile.d/kde.{sh,csh}. I tried to remove it and seems it doesn't effect the menus. Retried using normal username (ie. username = test) with re0831.0 After kpersonalize, restart X The menu works fine bero, do you have any idea on it? Thanks
BTW, kdebase doesn't effect the outcome. kdelibs is the main package here.
Also please look at "Additional comment by haarbye" in Bug 35863
kdelibs-2.2-10 seems to fix this problem but users should logout once to take effect of the kpersonalizer settings. (And Qt3/KDE future ver. will improve this inconvinience)
Seems kdelibs-2.2-10 does not works for root user. Some other results that might narrowed down the bug: Using re0831.0 with kdelibs-2.2-10 and kdebase-2.2-11 2.2 Way Procedure: rm -rf .kde*; startx; kpersonalize; exit; startx Results: - normal user kind of works after a restart (90% of translations), still have little part of menus that doesn't uses the translation (e.g. in JP locale's main KDE menu, Control Center, Find Files, Help, Home Directory's translation is missing) - root does not work (50% of translations) (ie. same as after kpersonalize) Another way (old KDE 2.1 config method) Procedure: rm -rf .kde*; startx; skip kpersonalize; set language and locale in kcontrol; restart; Results: - translation shows on all user (100%) (root and normal) Seems there are something for lang & locale that kcontrol does but kpersonalize doesn't. Looking at the kcontrol methods, kpersonalize methods, and patch while waiting the sync for latest build.
However, in the case where I blow away the .kde* directories, I see a hang next startx on nspluginscan. Odd.
I see this hang for a freshly installed user too. Full install.
Removing plugger fixes the nspluginscan hang.
notting: The nspluginscan problem (not a bug btw, itjust can't handle immensely broken plugins) should already be fixed in kdebase-2.2-11 from dist-7.2-HEAD (please verify). llch: kpersonalizer does not make a difference between root and non-root users. Did your diff show up anything, or is it just like yesterday's?
Diffs are just simliar to yesterday. There are no related differences between using kpersonalize and kcontrol configured.
kdebase-2.2.11 + re0905.2 still has the hang-up problem beause of nsplugin.
Installed re0905.2 and install kdebase-2.2-11 on the top kdebase-2.2-11 still does not solve the problem of nspluginscan, have to delete /etc/pluggerrc to make it go through (ie. mv /etc/pluggerrc{,.bak} ) Also the translations still having problem as I mention in last test for kpersonalize and kcontrol. Also looked at both sources and seem there aren't any different between those two methods.
llch wrote: > normal user kind of works after a restart (90% of translations), still have > little part of menus that doesn't uses the translation (e.g. in JP locale's main > KDE menu, Control Center, Find Files, Help, Home Directory's translation is missing) type `(cd /usr/share/applnk && touch *.desktop)` (as root), then "Control Center, Home, Help, Find ..." in K menu are localized. How about the influence of the cache or anything related, of kicker, started up at 1st time in C(?) locale before "kpersonalization" ?
This is fixed in the current release.