Hi!
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.
Tony has advised me to start building a todo list.
More than a list what I've written is an outline of
different ideas.
Here is what I've got up to now after many hours of
thorough research and painstakingly accurate work (;-).
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.
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.)
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? Is it possible to have a
mechanism that would allow the work of translators without
having them to build spambayes from source?
I didn't mention localization issues. Are there any? Don't
think so, right?
Anyway, I would follow any tech decision the developers
set in this area.
c) Delivery machinery.
We can have external language packs, a multilingual
distribution or complete installers per language.
Lang packs are easier to deal with because they can be
managed independently of the mainstream developement but
it would imply that the main installer will be in english.
We can start distributing external language pack and later
integrate them in the application installer.
Given that Outlook is monlingual I can't think that a user
would demand to have SB in different language(s) than its host
but could it be a requirement for the other tools?
d) Deploy a beta for one or two languages.
The first multilang (multi==more than one) SB version.
e) Establish the procedures for merge nondev->dev collaborations.
I will need a procedure or guidelines for the results of our
work.
f) Publish a HowTo doc.
It will be the guide for translation volunteers.
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.
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. ;-)
Sure I'm leaving lots of tasks out.
Regards,
-Hernán.