tameyer at ihug.co.nz
Wed Oct 6 05:13:34 CEST 2004
> My name is Hernán Foffani and would like to collaborate
> translating SpamBayes to Spanish while providing a general
> framework for other different languages as well.
> I also offer myself to search for foreign language
> volunteers and coordinate their work.
And even more so :)
> 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
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.
> b) Decide on the technical means (gettext or whatever)
> Ideally I'd rather use a dictionary based for the
> string literals where the message database is outside
> Spambayes' source code. Like gettext. It doesn't burden
> developers too much and it doesn't break the application if
> some language translation falls behind (it will happen.)
>From the little I know (I haven't done any translation work before) gettext
seems the appropriate choice for everything apart from (but maybe also
including) the Outlook plug-in.
> 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.
> Is it possible to have a
> mechanism that would allow the work of translators without
> having them to build spambayes from source?
> c) Delivery machinery.
I don't really know much about this. We can probably figure it out closer
to a release time.
> e) Establish the procedures for merge nondev->dev collaborations.
> I will need a procedure or guidelines for the results of our
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.
> f) Publish a HowTo doc.
> It will be the guide for translation volunteers.
This is a good idea. It could go in the README-DEVEL.txt file probably
(along with the instructions for building releases, and so on).
> 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.
> 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.
More information about the spambayes-dev