Re: [Openinteract-dev] Small i18n issue

[Teemu A. <te...@io...>]

> Step 4 would probably be an issue for the Controller - OI2::Controller::Raw
> should never re-code anything, and alternative controllers like, let's say
> for outputting PDFs - probably shouldn't recode their stuff, too.

I do agree. Although content_type should not include charset=iso-8859-1 as it 
does now.

> This would allow OI2 to use UTF-8 only in it's internal processing, but
> serve frontends with potentially different character encodings.

Utf8 atleast for internal data presentation is the way to go. I would also pay 
attention that utf8 from backend to frontend is also possible without losing 
any bits or forcing to certain character set in the middle. i.e. russian 
interface with chinese content should be possible. This of course requires 
that all the backends speak utf8.

> 1. get the charset from the request
> 2. encode all parameters as UTF-8 when fetching them in the request object
> (all but uploads)
> 3. set the Content-type: charset="foo" for the response (if needed).
> 4. encode all output in the Response object to the appropriate charset just
> before sending it (if needed).

For full UTF-8 support, also:

5. translation files (I18N/maketext framework) should be in standard GNU 
gettext (PO) format which is binary safe, instead of the current system which 
is poorly utf-8 compatible
6. Reading/writing OI2 configuration files should also be utf-8 compatible, 
with something like:
open( INI, ">:utf8", "action.conf" );
7. Searching and text parsing should be utf8 compatible. This means use utf8; 
and support for utf8 on the database backends. At the moment =~ /\w/ doesn't 
work very well with utf8 content ;)

Full support most likely requires perl 5.8.x =(... 5.6.x utf8 support just 
sucks (Encode module for example does not work with 5.6.x).

-- 
--------------

Teemu Arina
www.dicole.org