On 07/18/2014 12:55 PM, Dimitris Glezos wrote:
On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin
> 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.
Right, but the hardware is a commodity. It doesn't lock us in.
If Transifex was a commodity frontend for translations, I'd have no
problem with it.
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.
I don't know what "We" is, bu I think it would be a sad world if only
the Board pushed for Fedora's first foundation...
> It has been mentioned on this list that sharing the translations
> multiple sites, so the "pragmatists" can get their features and the
> 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).
Yes, I agree the solution with direct access to Git sucked. The current
Transifex is certainly better, especially for the average/casual user.
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
Nevertheless, Github is the best option around if you *just* want a Git
repo hosted, without any of the frills.
It works great for mirroring a project hosted elsewhere.
Also, it's easy to contribute to a Github-hosted project if you don't
want to touch Github -- mail a patch, maintainer merges&pushes, done.
Transifex? IMO not so much; the the platform wants to be the canonical
location of all the data. And when I merge a PO patch upstream, updating
Tx is inconvenient (Will translations be lost if I just upload the PO?
Is it possible to roll back if I screw up?).
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
In short, Transifex grew. Congratulations!
Surely that doesn't that mean every individual design decision you made
along the way was perfect.
Successful L10n Community Managers aim high on
these metrics and track them like crazy. Where the files are actually
stored is gravy.
As Yuri Chornoivan says in a separate mail.... not necessarily true.
(He presented it as his personal opinion, but consider: for a project,
Yuri is easily worth dozens of average translators. In FreeIPA,
Ukrainian is always up 100% a few hours after I upload the POT. I don't
know how the man does it, really.)
What the average future user wants is not what power users want.