Planning a future L10N infrastructure (including Fedora)

[Asgeir Frimannsson]

(forgot to cc tx-devel)

On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote:
> On Tue, 16 Sep 2008, Asgeir Frimannsson wrote:
> > > > Thoughts and comments, all sorts of comments, are very welcome.
> > >
> > > Please correct me if I'm reading this wrong but I see "transifex is
> > > great or close to it" and "here's how we're going to build our own
> > > solution anyway" ?
> >
> > Yes, "Transifex is great and will continue to serve us".
> >
> > BUT:
> >
> > If you look at the state of the art in L10N outside the typical Linux
> > projects where PO and Gettext rule, you'll notice we are very short on
> > areas like: - Translation Reuse
> > - Terminology Management
> > - Translation Workflow and Project Management
> > - Integration with CMSs.
> > - Richer Translation Tools
> >
> > This is an effort in narrowing that gap, and I can't see that effort work
> > by evolving an existing tool from this 'cultural background'. Yes, we can
> > get some of the way by developing custom solutions for e.g. linking wikis
> > to Transifex for CMS integration, or using e.g. Pootle for web-based
> > translation. But we would still be limited to the core architecture of
> > the intent of the original developers, which is something that would
> > radically slow the project down.
> >
> > That said, I am not talking down Transifex, and the fact that someone in
> > the community has sacrificed a lot and done a great job in getting us
> > this far within Fedora.
>
> Correct me if I'm wrong though, instead of forking or adapting or working
> with upstream, you are talking about doing your own thing right?

We have a goal of where we want to see L10N infrastructure go, to enable us in 
the future to provide internal (translators paid by Red Hat) and community 
translators with tools to increase their productivity as well as better tools 
to manage the overall L10N process. If there is an 'upstream' that provides 
this, or a platform on to which we could develop this, then yes, we would 
consider 'working with upstream' or (in a worst-case-scenario) forking 
upstream. 

So to answer your question bluntly, YES - after 4 years involvement in 
industry and community L10N processes - I believe we can do better. But 
holding that thought, remember that this is in many ways 'middleware', and 
making use of e.g. the vast amount of knowledge invested in Translate Toolkit 
(file format conversions, build tools, QA) makes sense, and I'm not saying 
'forget about all that we have invested in tools so far'. In addition, we are 
pulling in resources from other communities on this (JBoss, people in the L10N 
industry and academia), so we're not talking about or attempting to pull 
attention away from Transifex. (If so, we'd at least consider doing it in 
Python!). Still, we find it very important to develop this in the open and 
accept ideas and contributions from the wider community, including people in 
the Fedora infrastructure.

Regarding building on top of Transifex, I think it is much better that these 
two projects 'compliment' each other in the near future. Someone with 
Dimitris' caliber, character, passion and vision is very rare (only flaw I can 
see in him is I think he's a Gnome guy, rather than a KDE guy - but I can see 
beyond that ;) ), and I honestly think it would be both wrong and counter-
productive to attempt to 'hijack', fork or radically change core direction and 
architecture of a project that seems to finally gain traction way beyond the 
Fedora-circle.

cheers,
asgeir