L10N Infrastructure Roadmap (was Re: FLP Meeting 2009-01-28 IRC Log)
asgeirf at redhat.com
Mon Feb 2 01:31:11 UTC 2009
(added transifex-devel to cc)
----- "Noriko Mizumoto" <noriko at redhat.com> wrote:
> 1月 28 04:31:36 <ankit>
> 1月 28 04:32:11 <ankit> i just linked the page from #agenda
> 1月 28 04:33:46 <glezos> ankit: Good list. Maybe this is something
> we might want to discuss on the list instead of here?
> 1月 28 04:34:06 <glezos> ankit: Many of the points are valid, but
> need some coders to write tools to fix them
> 1月 28 04:34:29 <ankit> glezos: ah, so it's fixable?
> 1月 28 04:34:41 <glezos> ankit: everything is fixable. :D
> 1月 28 04:35:03 <ankit> ah cool
> 1月 28 04:35:22 <glezos> For the first point, I was thinking that a
> web-based tool or a simple CLI will help. Because of big changes in
> and DL, we haven't dared go on with a CLI yet.
> 1月 28 04:35:22 <ankit> glezos: so, what would you suggest to get
> all fixed?
> 1月 28 04:35:34 <glezos> I hope we will have one at some point,
So let's take this discussion to the list :)
Since the first recorded Transifex-commit in Nov 2007 until Dec 2008, 176 out of ~450 unique FAS users (in the cvsl10n group) committed translations through the system, a few commits away from a total of 5000 commits to 86 modules. Transifex remained fairly stable for F10 Translations, but Damned Lies was (as usual) acting up on a regular basis. Documentation-statistics for Publican didn't work for F10, as Damned Lies has issues with having a PO file for each XML file withing a project.
The new Django-based Damned Lies and Transifex looks promising, and will hopefully solve many of the issues we experienced through the F9+F10 cycle.
However, at this stage I want to take a step back from the technical reality of our existing L10N workflow and systems, and look at where we want to go with Fedora L10N onwards. As a contributor to Fedora, my main passion is to enable translators to create consistent and good quality translations through open collaboration; ensure that Fedora is the easiest distribution to contribute translations to; and also work towards Fedora becoming a natural choice for translation and QA of upstream projects such as Gnome and KDE.
I believe we have a long way to go to reach a stage where Fedora is in this position. What we have today is a developer-centric solution to the problem, and only covers the task of retrieving and submitting PO files from upstream VCSs. What translators deserve is a translator-friendly system, where they can focus on translation-related tasks, with tools that aid them in working effectively, without sacrificing quality. I started this mail by quoting some statistics as a measure of the success of the current infrastructure. Now, measuring translation infrastructure success in the number of VCS commits is just plain wrong in the first place, but still, the initial version of Transifex was a big step forward as translators now don't have to deal directly with VCS tools.
As Ankit mentioned, an initial list of Issues and Requirements for Fedora L10N is listed on the following wiki-page:
(also note the discussion 'tab' at the top of the page)
I thought it might be useful to have a forum for open discussion about what works and does not work with the current infrastructure, and how we can make it better for future iterations of Fedora. Above I've presented a few ideas and requirements. However, it would be very interesting to read comments, ideas and suggestions from you Fedora-translators, about what is working well, and ideas on how to improve what is not working well.
Based on this input, perhaps we can have an open discussion on where we want to go, and look at the resources we can each contribute to making Fedora better, as well as looking at how Damned Lies, Transifex, as well as e.g. Translate Toolkit & Pootle  and upcoming tools like flies  fit in.
More information about the trans