On Fedora's Localization platform

[Dimitris Glezos]

On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori at redhat.com> wrote:
> Tools are *not* just tools. Relying on superior tools that are graciously
> provided, but can be taken away at any time, can be quite dangerous.

The analysis on the level of danger and cost/benefit is missing. This
is Board's responsibility to define. The Board could demand an
agreement with "we can use it for free and export all important data
(+historical) for the next 10 years" -- and that could be good enough
for the Board. There are other areas where as a project we're taking
the risk, like with some of the hardware of our infrastructure which
runs closed firmware we don't control.

I'd expect the L10n project to be primarily concerned about what
matters most to it: making Fedora L10n a hugely successful project. We
should be the ones willing take risks to achieve the core project's
goals, push hard to have what we need, and the Board should be pushing
back.. not the other way around. This, of course, requires strong
leadership and governance.

> It has been mentioned on this list that sharing the translations between
> multiple sites, so the "pragmatists" can get their features and the "purists"
> can keep their freedom, is not feasible. This makes me sad. Why can't
> Transifex or Zanata be just frontends for the data, sort of like Github is
> for Git?

Short answer? We tried it. This is how the first version of Transifex
worked: it read git and committed back. I could write a huge list with
the benefits. In short, users hated it. User experience sucked,
translators were unhappy and developers simply did not translate their
apps. In the end, this was important for 1% of the users. Put simply,
what we originally designed is not what the users wanted. Plus, it did
not achieve the core goals of the localization platform: to make
localization as widely used as possible (= what future users want).

GitHub's story is similar. GitHub is so much more than a git
front-end. The true power of GH is the collaboration and
communication. First it was ACLs and team management and then came
pull requests, reviews/comments on code, integration with Issues and
Wiki, integration with chat/issue tracking etc. This is too much and
too complex metadata (+ functionality on top of them) to store in an
external DB/repository.

When Transifex started with VCS integration we had less than 500
projects translated. Today there are 20.000. And the more important
numbers are even better (number of completed languages per project,
number of contributors, activity/month, proofread phrases Vs
only-translated etc). Successful L10n Community Managers aim high on
these metrics and track them like crazy. Where the files are actually
stored is gravy.

-d



-- 
Dimitris Glezos
Founder & CEO, Transifex
https://www.transifex.com/