I'd like to introduce you all to Og Maciel. He's a programmer (pet
projects Billreminder and PyLyglot), gnome developer, and a current
translator of XFCE, KDE, Openbox, and Gnome. He's also been in charge
of the entire Brazilian-Portuguese translation team for Ubuntu.
There isn't much that Og (pronounced Oggie) hasn't done when it comes
to translation.
I brought Og into our mailing list/group so that you all could ask him
questions and pick his brain so to speak. I know that he hosts and
has hosted his own translation projects for what he programs and I
also know that he's helped on large teams of people...I think his
experience is unique and could also help us out here.
So without further elaboration, please ask Og any questions you might
have....AND I'd like to ask that Og give us a couple of ideas on how
translation projects can organize and empower their members. Thanks
for helping Og! Please PCLOS i18n, ask him any questions you might
have!
devnet
This can be taken care of quite easily. I have a long working
relationship with Texstar and am confident that things can be more
than worked out. In fact, there have been many times in the past
where Tex has said he would like a multi-lingual DVD release. If we
can collaborate with Santa's Helper rpm rollers and this team, we
really could do something great after the next base release :)
Gettinther, I think you haven't read or didn't quite understand our discussion
at Google Groups. I must admit it's a little bit chaotic. So let me explain our
ideas and proposals here.
You are wondering why are not the translations sent upstream. Answer is easy:
there are close to zero translations that fit to upstream releases.
There are three groups of packages we maintain l10n for:
1. Packages that are not any specific to PCLOS and are not modified by any PCLOS
patches.
Such packages usually have good l10n (many of them come from Mandriva and
Mandriva is very i18n friendly). A agree with you, that we should not maintain
l10n for these packages and if, then only temporarily before our contribution
hits upstream. I think we do not have many translations of these packages in our
CVS/SVN. Example: kdebase, krusader, firefox
2. Packages that were born in PCLOS, made by PCLOS packagers and developers.
These should be definitely maintained by our i18n project. There are only few of
them but the count is growing.
Example: VIT, gtk-liveinstall
3. Packages that are taken from upstream but somehow modified to fit into PCLOS.
Such modifications usually also change the program messages and the l10n from
upstream is not sufficient for our needs. This is the majority of packages we
maintain l10n for. It's quite tricky - we must keep merging our translations
with upstream translations.
Example: drakxtools, synaptic, ...
What are our options to deliver our translations to users ?
1. Current situation: we can hope packagers will contact us and include our work
to their packages upon new release. This method is very unreliable.
2. After we somehow change the translations or after we add a new language, we
can contact packager and pursue him to add our modification and make a new
release. This is not the way to go: this project just doesn't have enough
manpower to negotiate with all the packagers all the time. Such administrative
would be very demanding. And what if someone refuses to include our translations
? Should we give up localizing that particular package ?
3. There could be a rule: no package will be put into testing if it doesn't
contain latest translations from i18n project. No exceptions. We could offer
packagers help with i18n, we could provide them with patterns, Makefile and
.spec snippets.
4. We could have (actually we already have) some translation release system to
easily:
* maintain translations together with information about package version
* merge our translations with upstream translations
* automate .desktop files translation
* build a (S)RPM with one command
This RPM would only contain translations and .desktop files - nothing else.
Never ever.
The RPM would be made in a such way that it will backup and replace any l10n
files already installed by the core RPM. We can use the "alternatives" facility
for that, together with triggers. I'm pretty sure it wouldn't break anything.
The main advantage would be that the packagers and developers wouldn't have to
care about l10n at all. Just internationalize your project - and we'll do the rest.
There is another advantage:
Minimizing network traffic. L10n packages would be very small and not all
packages would have its l10n counterpart (only packages of type 2 or 3). What if
the core package has 20MB and we've just added a Thai translation ? New release
would mean downloading 20MB for everyone, put it in extra l10n package and only
users interested in l10n would have to download few kilobytes on update.
OK, but what about repository metadata ? Again, only minority of packages would
have its l10n counterpart. L10n packages could have its own section that could
be disabled for English-speaking users by default.
5. The same option as point 4 but without official support from PCLOS devs. We
would have to maintain our own unofficial repository.
I prefer option 4 but would be happy with option 3 as well and would be very
unhappy with option 5.
I am not naive and I know that the decision is always yours and there's nothing
we can do about it. But I would be very glad to hear, that you are recognizing
us as the partners for discussion.