Hi,
I have a small annoying problem that most likely is quite trivial but can find the cause. All characters above ASCII 127 are converted to something else. E.g. 'ä' gets converted to ','. Funny thing is that on my server (FC4) the conversion is done like that but on windows computer they are converted to '?' chars.
On the machine where VDRAdmin is running characters are shown correctly. It seems to be related to language setting but can't figure out how to fix this. Could someone with more knowledge help me?
Br, Pasi
Hi,
I assume you use VDRAdmin-AM. What language/locale do you use in VDRAdmin-AM? Do you use any VDR patch, that changes its character encoding? Does this happen with all text or only with text that comes from VDR (e.g. EPG) ?
Regards, Andreas
On Monday 01 January 2007 20:51, Pasi Juppo wrote:
Hi,
I have a small annoying problem that most likely is quite trivial but can find the cause. All characters above ASCII 127 are converted to something else. E.g. 'ä' gets converted to ','. Funny thing is that on my server (FC4) the conversion is done like that but on windows computer they are converted to '?' chars.
On the machine where VDRAdmin is running characters are shown correctly. It seems to be related to language setting but can't figure out how to fix this. Could someone with more knowledge help me?
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Your assumption is correct: VDRAdmin-AM-3.5.2. I forgot completely the original VDRAdmin.
Local LANGUAGE is empty. LANG is en_US. In VDRAdmin I have tried: System, en_US* (all choices), fi_* (all choices).
VDRAdmin is not patched. Only configured during setup phase.
This conversion affects all text from VDRAdmin: labels, EPG, everything. They all are similar i.e. there is no difference between VDRAdmin created texts and EPG texts.
Br, Pasi
Andreas Mair wrote:
Hi,
I assume you use VDRAdmin-AM. What language/locale do you use in VDRAdmin-AM? Do you use any VDR patch, that changes its character encoding? Does this happen with all text or only with text that comes from VDR (e.g. EPG) ?
Regards, Andreas
On Monday 01 January 2007 20:51, Pasi Juppo wrote:
Hi,
I have a small annoying problem that most likely is quite trivial but can find the cause. All characters above ASCII 127 are converted to something else. E.g. 'ä' gets converted to ','. Funny thing is that on my server (FC4) the conversion is done like that but on windows computer they are converted to '?' chars.
On the machine where VDRAdmin is running characters are shown correctly. It seems to be related to language setting but can't figure out how to fix this. Could someone with more knowledge help me?
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Andreas Mair Andreas.Mair@linogate.com wrote:
What language/locale do you use in VDRAdmin-AM? Do you use any VDR patch, that changes its character encoding?
I'm using the UTF-8 patch (because I'm using Russian and German EPGs), and German umlauts are displayed incorrectly unless I tell the browser explicitly to use UTF-8. In any case, vdradmin-am should give a hint which locale it uses, by using the appropriate META header:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
... and use a portable encoding for buttons and menu entries, like ä instead of "ä", for example, because if I set UTF-8 in the browser, umlauted menu entries are incorrectly displayed. At the moment it appears that for example German is tied to ISO-8859-1 in the PO file. UTF-8 should be in the SUPPORTED_LOCALE_PREFIXES list, IMHO.
Hope this helps :-)
On Tue, 2007-01-02 at 18:46 +0000, Harald Milz wrote:
I'm using the UTF-8 patch (because I'm using Russian and German EPGs), and German umlauts are displayed incorrectly unless I tell the browser explicitly to use UTF-8.
Are debian packages with incorporated UTF-8 patchs available some where?
BRGD, Vladimir
Hi,
On Tuesday 02 January 2007 19:46, Harald Milz wrote:
Andreas Mair Andreas.Mair@linogate.com wrote:
What language/locale do you use in VDRAdmin-AM? Do you use any VDR patch, that changes its character encoding?
I'm using the UTF-8 patch (because I'm using Russian and German EPGs), and German umlauts are displayed incorrectly unless I tell the browser explicitly to use UTF-8. In any case, vdradmin-am should give a hint which locale it uses, by using the appropriate META header:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">... and use a portable encoding for buttons and menu entries, like ä instead of "ä", for example, because if I set UTF-8 in the browser, umlauted menu entries are incorrectly displayed. At the moment it appears that for example German is tied to ISO-8859-1 in the PO file. UTF-8 should be in the SUPPORTED_LOCALE_PREFIXES list, IMHO.
There is support for UTF8 but it has to be added manually. Simply run "./make.sh utf8add" and "./make.sh po" to generate the UTF8 locales.
Hope this helps...
Regards, Andreas
On Monday 01 January 2007 20:51, Pasi Juppo wrote:
Hi,
I have a small annoying problem that most likely is quite trivial but can find the cause. All characters above ASCII 127 are converted to something else. E.g. 'ä' gets converted to ','. Funny thing is that on my server (FC4) the conversion is done like that but on windows computer they are converted to '?' chars.
On the machine where VDRAdmin is running characters are shown correctly. It seems to be related to language setting but can't figure out how to fix this. Could someone with more knowledge help me?
Hi
This can accur from vdradmin not running in a locale with same charset as vdr uses. The only use-case we have found yet is utf8-system and vdr running with latin1.
For Gentoo we have this hack in the vdradmin-startskript at the moment:
When vdr is not utf8-capable (only when self-patched) then execute this code to switch of utf8-locale:
l=$(locale | sed -e 's/.[uU][tT][fF](-)?8//' -e 's/^/export /') eval $l
Perhaps it would help if epg.vdr would contain information about encoding (even if it is not even read by vdr this could be usefull, but just to inform other programs).
Matthias
-
Andreas Mair -
Harald Milz -
Matthias Schwarzott -
Pasi Juppo -
Vladimir Kangin