Re: Internationalisation

Hi,

character encoding - where should I begin?

It is true that LCDd does not handle anything else than single byte
characters as input from clients.

However, it does not assume any encoding - other than it contains
characters that can be parsed into commands.

Any data is passed to the drivers 'as is'. Some drivers map that (single
byte) characters to values in CGROM of the display. The Crystalfontz and
HD4480 drivers e.g. assume ISO 8859-1 as input by default and can handle
ISO 8859-5, CP-1251, KOI8-R as well.

The picolcd driver does not do any character mapping.


Currently I am fine with this, except the developer's guide does not
talk about it. Clients are responsible for sending single byte
characters to LCDd (whatever encoding).

I am not agaist using UTF-8 as input. If we want to use it, my opinion
is not to apply it to some 'widget text value', but to the whole input
before it is parsed.

By using libiconv we may get rid of mapping non ISO 8859-1 encoded input
to CGROM values. Or not.

However, auto-detecting the system locale only works if client and
server run on the same system and share the same locale (which might not
be true for LCDd started at boot time and a client that runs in a user
session).

Library dependencies and compatibility are another topic for some future
discussion.

Regards,
Markus


On 27.02.2014 21:47, Martin Tharby Jones wrote:
> Hello,
>
> I've attached a patch which provides a first step towards
> internationalisation of LCDproc.
>
> I'm a British English speaker with minimal second language skills so I
> apologise that I have only addressed those areas that are relevant to
> me. My problem was that I have a number of Celtic &  Gaelic tracks in
> my music collection and the accented characters used in those
> languages were not being displayed correctly.
>
> UTF-8 characters greater than 0x7F were displayed as two or more
> strange characters:
>
>
> With the patch and a display that supports ISO-8859-1 most western
> European languages can be displayed:
>
>
>
> I've also added string support for Unicode on graphic displays:
>
>
> I've not done title or scroller widgets because I feel graphic
> displays should support pixel level scrolling and proportional spaced
> fonts which would require more work than I am prepared for (I don't
> have a graphic display). Basic string support was coded as proof of
> concept and as a test case.
>
> There is obviously more to do but the code in the patch meets my
> requirements and I hope will be of use to others.
>
> Further work I have thought of:
>
>   * Conversion of menu text
>   * Use of gettext() and conversion for system screens
>   * Use of gettext() and conversion for lcdproc screens
>
> Regards
>
> Martin