Planning a future L10N infrastructure (including Fedora)

[Dimitris Glezos]

2008/9/17 Asgeir Frimannsson <asgeirf at redhat.com>:
> On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote:
>> > >
>> > > 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.

For the record, I believe these are some fine ideas, which I would
like to see added to Transifex as features (eg. through plugins). I
have been discussing most of them with people around conferences for
the past year. An example: Tx already downloaded all the translation
files from upstream projects, so if someone requests a translation
file, why not be able to pre-populate it using existing translations
from all the other projects (translation reuse)?

Also, I should mention that Transifex isn't (and will never be)
specific to a particular translation file format (eg. PO) or any
translation repository. I'd like to support translation of both PO and
XLIFF files. And also support not only VCSs, but CMSs, wiki pages and
even arbitrary chunks of text. Transifex's goal is to be a platform to
help you manage your translations.

>> 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.

The Translate Toolkit folks are a very friendly bunch, actively
maintaining and extending the rich library, and always open to
suggestions. Maybe some (if not all) of the features could be done in
TT, and the rest that might not fit there, as Python libraries to
maximize interoperability and community involvement.

I also think that Transifex could serve as the "UI" for a lot of
translation-specific tasks. If there's a library that does X, that
would help people manage their translations or leverage Transifex's
strong points of "I read a lot of repositories" and "I write to some
repositories", then we could provide a web wrapper around it. (eg.
search for string "X" in all translation files of language "Y", or
"mark <this> file as a downstream of <that> and send me an msgmerged
file whenever <that> changes".

> 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'.

It might be my poor English or the fact that I usually read long mails
at night, but despite the lengthy descriptions I still don't have a
clear picture of exactly what problem you'd like to solve, and the
reasoning behind the decisions being made.

Don't take me wrong -- I think there are some good ideas. But I feel
it would be too bad if you guys didn't invest on top of existing tools
(TT for file formats, Transifex for file operations and UI, OmegaT for
translation memory) or just isolate specific solutionsthat don't fit
into other projects in well-defined libraries (do one thing, to it
right). Sure, it takes a lot more effort to work *with* other people,
but it is usually worth it. :-)

-d



-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--