[spambayes-dev] I18N

[Hernán Martínez Foffani]

>> a) Define the translation units.
>>
>>    I would like to focus on small but complete units of    the
>> application.
>>
>>       1. Outlook addin
>>       2. Windows tools
>>       3. Win32 bundle docs
>>       4. Win32 installer
>>       5. Other sp_* tools
>>       6. Website
>>
>>    The order of the list reflects a personal preference
>>    (I'm an Outlook user) not a technical reason.
>
> I would replace #2 with "sb_server".  There aren't really any Windows
> tools other than the installer and the Outlook add-in (well, there's
> the tray application, but that would take almost no work and could be
> included in the sb_server work).  Other than that, it looks good -
> including the ordering, I would say, although sb_server is likely to
> be an easier prospect than the Outlook plug-in.

Besides sb_server and sb_tray in my SB bin directory I also have
sb_pop3dnd, sb_service, sb_upload and setup_server.  Never used them
though.

(Regarding on which I should start, see below)

> I would say that this should definitely be done against CVS Head -
> i.e. this will end up having a result for a 1.1.x release, not a
> 1.0.x one.  We should also stick to interface changes rather than any
> changes necessary to work with languages where (eg)
> split-on-whitespace doesn't really work (there's a separate sf
> tracker about that).  Tim's decreed that that sort of thing should be
> a branch, and his reasoning works for me.

Sorry don't get it... Do you suggest to work (me) on a branch or to
send patches against HEAD?  For the time being I rather send patches
to SF against cvs' head.  If I see that you work too much and/or my
code falls behind then I'd ask you to branch SB for I18N if possible.
We can decide later who will merge it back. heh...

Of course I will work *only* in the interface part of SB.

>>    I understand that there's a problem with outlook's dialogs
>>    which are RC based.  I admit that I never used rcparse.py
>>    before.  Do you think that integrating rcparse.py with
>>    gettext (or similar) can work?
>
> I think something could be done.  The .rc files are generated by the
> MS tools - does anyone know what they do for internationalisation
> work? Following that would possibly be a good idea.  Otherwise the
> scripts could probably be adapted to use (eg) gettext.  This is the
> main reason that the Outlook plug-in will be much more complex than
> sb_server, however.  It would be the first thing to figure out, I
> would think.

I want to start with a kind of a proof-of-concept on the Outlook
plugin.  If I manage to translate a couple of dialogs and string
literals then I'd feel more confortable to do the rest of the
repetitive job.  I wouldn't like to find that after patching
sb_server for gettext the Outlook plugin can't use that approach.

My goal is to build or find a framework for translators as
small as possible.

>> c) Delivery machinery.
> [...]
>
> I don't really know much about this.  We can probably figure it out
> closer to a release time.

OK.

>> e) Establish the procedures for merge nondev->dev collaborations.
>>
>>    I will need a procedure or guidelines for the results of our
>>    work.
>
> Use the sourceforge system to submit patches against current CVS.
> You can assign them to me if you like (anadelonbrin).  If it turns
> out that someone needs to be checking in things all the time, then we
> can organise check-ins rights and so on.

Fine with me.

>>    By the way, is there a way to set a test environment for the
>>    SB Outlook addin?  I would like to have more than one SB version
>>    installed without sharing the database.
>
> If you're running from source, then you can just run the addin.py
> script from a new checkout of the directory.  To have a different
> data directory/configuration file, you can use the
> default_configuration.ini script technique described in the docs, I
> think.  Just put one in each Outlook2000 directory pointing to the
> appropriate place.

Err.... Sorry.  I think that what I really want is to share the db.
But don't mind, I'll figure it out.  Thanks.

>> g) Ask for volunteers and coordinate their work.
>>
>>    My plan is to have at least two translators per language for
>>    better QA. The exception of this rule will be Maori. ;-)
>
> This is a nice goal, but I'm not sure whether it will work or not.  I
> wouldn't want to turn anyone away just because they were the only
> person willing to do a language.

You're probably right.  Now imagine someone sending me a message file
containing say "skcus seyab maps" in it, and claiming to be the
kamandarian translation...

-Hernán.