ubuntu-manual team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

El ds 06 de 11 de 2010 a les 22:47 +1300, en/na Benjamin Humphrey va
escriure:
> While I'm not a translator, here is my 2c.
> 

And here are my 2c as a translator:

> 
> I think translations must begin only -after- the final english manual
> has been released, to ensure a full freeze and minimal disturbance and
> loss of work for the translators.

I agree with that. This is basically what all OSS projects which are
successfully delivered with native language support already do.

For translators it is extremely important to have a clear idea of when
they can start their work, so that changes in the code during
development do not effectively delete their contributions.

The fact is, regardless of the tool used to manage translations, if text
is change at the same time people are translating, their effort is going
to be wasted.

This means defining a string freeze shortly before release, ideally
having it published in the release schedule of the project and
announcing it on the project's communication channels.

>  I think it has basically been decided that in future, the manual
> itself, english or otherwise, will be released at least 2 weeks after
> the Ubuntu OS release date, because the Ubuntu developers have proven
> that they cannot enforce the UI freeze and continue adding things up
> to the last minute, sometimes even after release candidate.
> 
> 
> However, if we wait two weeks or more to release the English manual,
> and then we only start translations when that happens, we have an
> issue whereby the translations may take anywhere between one month to
> six months for completion - by which time we are fully into the next
> release cycle and one has to question whether there is point
> continuing translations of a manual which will be outdated in a couple
> of months. And herein lies the fundamental problem.
> 

With this I understand that on every single release of the manual the
whole text is rewritten from scratch and also do translations, which
would surprise me a bit.

My experience in translating large documents is that it is incremental
work. In general, there is an initial effort in translating the whole
documentation that can span through several releases, so it is often
unrealistic to think (unless the translation team is extremely active)
that a translation will be completed within the first or next few
release cycles of a project.

However, once the bulk of the translation has been done, it is much
easier to catch up with every release and deliver translations on time,
basically only having to translate anew the modifications of the new
release. I've rarely seen that a project's strings are completely
rewritten from scratch.

> 
> It is clear to me that we don't have the correct infrastructure at the
> moment to handle translations and writing alongside one another
> smoothly, rosetta on launchpad was never designed to handle large
> chunks of text formatted in latex, and our current solution by using
> po4a, 

As a translator, I am familiar with the issues of translating big chunks
of text - and the pain that they can be. However, other projects use
similar approaches (docbook + xml2po) and adapt to the infrastructure
constraints, delivering translations on every release.

> coupled with the known bugs in Rosetta

Which known bugs? Have they been reported?

>  provides a rather cumbersome, frustrating and slow process for
> translations.
> 

I cannot understand in which way translations can be cumbersome to
developers, nor how they can affect the release process.

Is it not just a matter of:

     1. Creating a .pot template after string freeze with a build rule
     2. Committing it
     3. Announcing string freeze in the mailing list
     4. Just before release, merging the branch with translations to
        trunk
     5. Build the final manual, building translations along the way

Which part of this process does not work, and why?

To me, it looks that the lack of a release schedule brings a bit of
chaos to translations. If there isn't one already, one of the things I
would suggest would be to publish a release schedule with milestones,
including the string freeze and release dates.

Let the translations teams manage their time and work and only worry
about sticking to the deadlines and building translations on the release
date.

You could also use a policy of only building those translations that
have more than 80% coverage, for example.

> 
> My advice would be to research how important it is that every single
> manual we release is available in more than one language, we should
> collect some statistics from the downloads to judge how popular they
> are and whether it is worth all of our time to go through the process
> every six months.

Again, I fail to see how translations can affect the release process. I
would suggest building them on every release, and let translations teams
worry if they are complete or not.

In terms of statistics, I haven't got any at hand, but I can tell you
that providing an English document to any non-English speaking LoCo is
rather not useful.

>  I think it would be much more beneficial for everyone if we only
> translated LTS versions of the manual, once every two years. This
> would leave significant time for translators to work, and while it
> won't provide the latest and greatest in languages beside English, it
> would certainly take a lot of strain off a volunteer team lacking the
> necessary infrastructure for such a mammoth undertaking twice a year.
> 
> 
> If we find that people do miss having the newest information available
> to them every six months in their own language, we could quite easily
> create change logs for each release as Jonas suggested, which would
> provide a nice and brief overview of the newest features. This could
> be small, maybe less than 3 pages, and would be translated within days
> of the release.
> 

The Ubuntu Manual is an awesome project. You've come very far in short
time, and I would love to see it possible to translate every edition of
the manual. This does not mean that all teams will be able to, but at
least it would give them the possibility and would provide them the
basis to incrementally manage to deliver a fully localized version in
future releases.

Please, remember also that you can always reach to the Ubuntu
Translators if you need any help regarding translations.

Keep up the good work!

Regards,
David.

[1] https://wiki.ubuntu.com/MaverickReleaseSchedule


-- 
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

Attachment: signature.asc
Description: This is a digitally signed message part