Mallard and Ubuntu-Translators and Translation Regressions

[David Planella]

El dt 26 de 01 de 2010 a les 09:14 -0500, en/na Kyle Nitzsche va
escriure:
> "A billion dollars here, a billion dollars there, and pretty soon 
> you are talking real money!"
> 
> I would like to get a subject on the record that deserve explicit 
> consideration respecting the proposed transition to mallard:
>  * Work for ubuntu-translators
>  * Likelihood of lower translation completeness for docs for some time
> 
> Taken together, I think these amount to another argument in favor of 
> transitioning to mallard in increments, rather than all at once.
> 
> Consider that:
>  * When a string changes, it has to be translated
>  * Into something like 50 languages
>  * And sometimes that translation has to be reviewed and accepted by 
> another person
>  * The transition to mallard is also a translation to topic-oriented 
> content, which will involve some re-writing
>  * Thus, there will likely be  some, perhaps many, string changes for 
> each topic, multiplied by the 50 or so languages.
> 
> That's a lot of new translation work.
>  * Has the actual quantity of this been estimated?
>  * Have discussions been held with Ubuntu-Translators to see how this 
> estimated work fits in with their workload?
> 
> Bear in mind that some language teams are not as active as others, thus 
> there might reasonably be expected to be regressions in translation 
> completeness.
> 
> This probable regression is a cost to doing this. It may be a cost worth 
> carrying, but it is one that has consequences. For example, in almost 
> every OEM project, the client writes bugs to the effect that help 
> translation is incomplete. We have to explain that the community is 
> doing the best it can. While not a critical bug, this definitely affects 
> the quality of the deliverable and of the user experience.
> 
> These issues (work for U-T and translation regression) could be 
> mitigated by implementing mallard on a topic-based schedule spread out 
> over a few releases. (This approach would have other benefits I've 
> discussed elsewhere.)
> 
> (ccing David Planella the translation community liaison.)
> 
> Cheers,
> Kyle
> 

Hi all,

I apologise the delay in my reply. After reading the Mallard threads and
the logs from the last docs team meeting, I understand most of the
points have been addressed and that (please correct me if I'm wrong),

      * Mallard will not be implemented in Lucid
      * It will continually be evaluated, with an onlook to use it for
        the next release (or whenever ready), with a current playground
        branch and with a spec for a potential migration

Regarding translations, Kyle is raising some valid points in terms of
potential regression and additional work for translation teams, and I'd
like to ask a few questions in order to understand in an early stage
what this would mean to translators.

      * I understand that the current documentation is already
        topic-based. If so, I assume the migration to Mallard would be
        mostly affecting packaging infrastructure and syntax, and not a
        complete rewrite of documentation. Is that correct?

My concerns regarding translations are simply that a migration is
properly communicated to translators and as much content can be reused
as possible. Translating documentation and reviewing it is a huge task,
one which cannot be compared to regular application translation in terms
of effort, so I'd like to only raise awareness on how changes can affect
translations and make sure the process is as smooth as possible,
gradual, and that translators are aware of changes at an early stage.

Regards,
David.

-- 
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Aix? ?s una part d'un missatge signada digitalment
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20100212/40ca0879/attachment.pgp>