Hello. I'm using utf8 locale and I have problems with reading messages from man and mplayer programs. I've already reported http://bugs.gentoo.org/show_bug.cgi?id=77175 about mplayer. Same about man: Both mplayer and man do not use getext for translating messages. They use their own mechanism, that does not take in account that there are exist different encodings for one language. For example in russian we have commonly used three encodings: koi8-r, cp1251, utf8. The problem is that all russian messages in man and mplayer are encoded with koi8-r and if one have other locale, utf8 like me, I can not read russian messages. Some crappy text is on my screen instead of informational message. Yes. I know that bug like this should be fixed by upstream developers. And I'm going to report about this problem to upstream developers. But this is long story... I'm sure that modern distribution should not show user quadrants instead of readable text. For example, Red Hat followers do not have such problems. There exist general tendency toward utf8 locale. Taking in account this fact I think it's necessary to give the rains of government in user's hands, while the programmers are looking for more general solution. As a partial solution we can use existant utf8 flag or better introduce new nls-utf8 flag and then add this something like this in man ebuild: if useq nls; then if useq utf8 ; then iconv -f koi8-r -t utf8 msgs/mess.ru > mess.ru mv mess.ru msgs/mess.ru sed 's/koi8-r/utf8/' msgs/mess.ru.codeset > mess.ru.codeset mv mess.ru.codeset msgs/mess.ru.codeset fi fi and something like this in mplayer ebuild: if useq nls; then if useq utf8 ; then iconv -f koi8-r ${S}/help/help_mp-ru.h > ${S}/help/help_mp-ru_utf8.h mv ${S}/help/help_mp-ru_utf8.h ${S}/help/help_mp-ru.h fi fi If there exist a better solution, please, tell me. But I think stange to force users either not to have localisation or to look for workarounds by himself. Let's do some uniform solution for now. There exist manpages-ru that also need such fix. All manpages are koi8-r encoded. I can do all necessary patches for this three packages, but first I want to listen for developers opinions about what is the best way to implement this? Or more specifically what USE flag it's better to use? Thank you for your time, Peter. Reproducible: Always Steps to Reproduce:
MPlayer since 2005/02/26 has a --charset configure option that will convert the help messages to the given charset. It will only work for languages where a help/help_mp-??.h.charset file exists - unfortunately not all translators responded to my call to add it. Man pages are a different thing - I had hoped that man would be able to handle it.
Hi, Some users have reported the same problem with german language in the forum. Mplayer: http://forums.gentoo.org/viewtopic-t-350218-highlight-unicode.html Man:http://forums.gentoo.org/viewtopic-t-357032.html I think, Peter has made a good solution-suggestion for this problem. greetings Martin
Created attachment 67734 [details] mplayer-1.0_pre7-r1.ebuild with unicode support Here latest ebuild (mplayer-1.0pre7-r1 from rsync) with unicode support. Now configure script support option "--charset". Added keyword - unicode. Supported language: bg cs de en hu pl ru uk. I added this code: [quote] # Added workaround for support unicode if use unicode then LANG=( $LINGUAS ) if [ -e ${S}/help/help_mp-${LANG[0]}.h.charset ] then myconf="${myconf} --charset=utf-8" else LANG_CC=${LANG[0]} if [ ${#LANG_CC} -ge 2 ] then LANG_CC=${LANG_CC:0:2} if [ -e ${S}/help/help_mp-${LANG_CC}.h.charset ] then myconf="${myconf} --charset=utf-8" else ewarn "Can't convert ${LANG[0]} or ${LANG_CC} to Unicode, leave it as is." fi fi fi fi [/qoute] $LANG_CC variable need for locale with name zh_TW, pt_BR etc. I hope, this would be useful :).
*** Bug 105241 has been marked as a duplicate of this bug. ***
Created attachment 74237 [details] mplayer-1.0_pre7-r1.ebuild (20051201) with unicode support Here new version synced with portage tree. And so... ANYBODY HEAR ME? Who lead utf8 team? Where comments for first bug file? Hey, don't sleep!
(In reply to comment #5) > Created an attachment (id=74237) [edit] > mplayer-1.0_pre7-r1.ebuild (20051201) with unicode support > > Here new version synced with portage tree. > And so... ANYBODY HEAR ME? Who lead utf8 team? Where comments for first bug > file? Hey, don't sleep! I am already ansver on your question. It's bad things about used iconv in ebuild and convert text to utf-8. I think it's would be better if upstream provide separate transates for different locales.
he just sets --charset=utf-8 with unicode use flag
*** Bug 120734 has been marked as a duplicate of this bug. ***
Created attachment 78369 [details] mplayer-1.0.20060102-r1.ebuild This ebuild works for me fine...
could you please past it also as diff? (yes, I'm lazy sometimes)
Okay, here it is... 13c13 < v4l v4l2 win32codecs X xanim xinerama xmms xv xvid xvmc" --- > unicode v4l v4l2 win32codecs X xanim xinerama xmms xv xvid xvmc" 434c434 < --- > use unicode && myconf="${myconf} --charset=utf-8"
And to DEPEND we will need to add line: unicode? ( app-i18n/enca ) When I removed enca after compiled it with --charset=utf-8, then it fails to start: $ mplayer 040\ Autoskola.avi mplayer: error while loading shared libraries: libenca.so.0: cannot open shared object file: No such file or directory So I think it depends on it...
*** Bug 124925 has been marked as a duplicate of this bug. ***
Created attachment 81278 [details] mplayer-1.0.20060302 with utf8 support Btw: Enca is not dependency... Please add it to tree with this modification, it is not dangerous, it's just one safe option for ./configure, which 'll make good. It's really boring to edit each new versions ebuild... Thanks.
(In reply to comment #15) > mplayer-1.0.20060302 with utf8 support One question: why utf8 instead unicode? It is pricipial difference or not?
Sorry, it's me again :) Ebuild work pretty fine for me (Russian with unicode), but in console mplayer says: "libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk" ++ more same warnings below. This is no critical error, mplayer runs without crashing.
> (In reply to comment #15) > > mplayer-1.0.20060302 with utf8 support > > One question: why utf8 instead unicode? It is pricipial difference or not? > Well, in ebuild's added line: use utf8 && myconf="$myconf --charset=utf-8" So I think utf8 is better choice. But doesn't matter.
>As a partial solution we can use existant utf8 flag or better introduce new nls-utf8 flag and then >add this something like this in man ebuild: you can look at http://bugs.gentoo.org/show_bug.cgi?id=93664 with full fix, it works fine in ru_RU.{CP1251,UTF-8,KOI8-R} or should work :)
Fixed, innit ?
Well, one year ago (hehe, anniversary). So, latest ebuild mplayer-1.0-20060415 work fine, but solving problem by disabling l10n... too hard, is didn't? For unknown reason section of hadling LINGUAS commented. I rollback to mplayer-1.0-20060408 and for me mplayer runs with russian cyrilic simbols... at last.
it will be reenable on mplayer release (or withing a week). I disable it just because not every language was updated to the new infrastructure fixing localization problems.
See http://bugzilla.mplayerhq.hu/show_bug.cgi?id=441 :-)
This bug is now a Tracker to get an overview of affected packages, but no longer contains patches/bug-descriptions/...
Closing this as utf8 herd no longer exists (it was dead for ages) and the only two packages with reported problems are only two and both with their own bug reports