[spambayes-dev] State of I18N

[Hernán Martínez Foffani]

[edited]
> Current code for sb_server HTTP interface doesn't allow
> some singlebyte/multibye [. Their] character sets
> (codepages) are not allowed since they contain bytes
> [that do] not match
> '[\t\r\n -\176\240-\377]' which are not allowed by xmllib.
> 
> UTF-8 will be allowed by adding option
> accept_utf8 to xmllib.XMLParser.__init__() in PyMeldLite.py.
> So (at least internally) UTF-8 must be used for character set of 
> translated literals on HTTP interface.

Thanks for the info.  I guess I have to work on that a bit more.

> On the other hand, leterals in dialogs, menu items etc. on
> Outlook plugin need to use ANSI codepage, e.g. CP1252, CP932
> etc.
>
> I suggest all of variable strings for Outlook plugin are
> contained in .rc file as STRING resources (if rcparser.py
> could support STRING resource).

It doesn't :(
rcparser supports neither code_page pragma nor STRING resources
right now.

I'm thinking aloud here...  If rcparser.py grows to support
STRING_TABLE that wouldn't solve the hole problem, right?
Because in a graphical resource editor you can't map captions
and labels to STRING_TABLE entries.

Let's suppose that rcparser can detect the resource
code_page.  A translator could draw the dialogs with their
captions and labels in a resource editor of her choice.  If
this editor writes the correct code_page in the new dialogs.rc
file the parser could pick up the pragma and decode the strings
accordingly.  The next step, dumping the dict to a .py by rc2py,
would need to mark that .py with the corresponding encoding
declaration or dump it in utf-8.  During runtime SB would
import such .py with the correct encoding.

The rest of the strings to be translated (the string literals
in SB python source code) goes through gettext.  The translator
should specify in the messages table file which encoding she's
using.  I guess that it may even differ from the one used in
dialogs.rc

Could this scheme work?

-H.