5:17 a.m.
Hey all,
I'll share some of my thoughts at this point.
*GIST*
- *Freedom* is more than just access to a tarball. What kinds of Freedom
is Fedora enjoying and giving up by using a platform like Transifex or
GitHub?
- What is the *Board's position* about using non-open-source but
open-friendly services? How much should we sacrifice to only run
open-source on our servers?
- Research thoroughly all possible solutions and find out what exactly
we'll be sacrificing and gaining. *Pootle* is much more trusted than
Zanata.
- Ask all key Fedora L10n people. Past and current.
- Any switch should be led by a technical Fedora localization person.
- The goal should be to make Fedora L10n a successful project. The tools
are just tools. The most important community features in Transifex have not
been used.
*BACKGROUND*
My contributions to Fedora nowadays are limited to supporting the L10n
project with our Transifex instance. I used to be a member of the Fedora
Board in the past. I see there's still the title "Fedora Localization Lead"
next to my name, but I suppose that's mostly because no one else took the
role. Today I basically make sure the community has what they need from
Transifex. I trust Piotr Drąg (raven) for any L10n leadership questions I
have.
Today a decision is being brewed on the basis that Transifex is not
open-source. As I mentioned, this is a discussion which needed to happen.
But I find the way it's being discussed disappointing to all the years of
hard work many individuals have put to establish a successful L10n platform
for Fedora (including my own). Many people in Fedora (and Transifex)
have *invested man
years to make this work*. We haven't even discussed "what are the key
things we need from our L10n platform"?
Following are my thoughts. I'm writing these with an effort to wear my
Fedora L10n hat as much as possible. But the POV does also include my roles
as Transifex's CEO, Fedora's Localization Infrastructure Lead for the past
6 years, and as one of the most experienced people on open-source
localization.
*ON FREEDOM*
When I was young I was looking at freedom in a different way. I was more an
open source zealot than today. I cared mostly about openness of the code.
It didn't matter if there was only one engineer hacking on the code. What
mattered was the license and little more.
Gradually I started realizing one of the reasons I loved Fedora was that it
valued highly quality and community participation. It valued relationships,
productivity, happiness, innovation. We valued meritocracy more than
democracy. Succeeding as a distributions was more than just having the
sources of packages.
*I'm not a fan of the spin put on Freedom in this discussion*. Fedora is
free to use Transifex forever. It's free to export all data at any point
(including all past translations and all the history of the translations so
far) to move to another platform. And it was free to use real people from
our team working on improving the platform constantly and adding new
features. I've met a lot of people in Fedora. The smartest ones knew very
well that *Freedom is not a one-colored attribute*.
*MIGRATING*
Migrating from one platform to another will have *major costs*. I led the
original migration from Elvis
<http://fedoraproject.org/wiki/Archive:L10N/Tools/Plans> to Tx. It required
many meetings with stakeholders, research, experiments. In the end, *it
costed us more than half our translators*.
Assuming the Freedom discussion is resolved and the benefits of the
migration outweigh the costs. If I were leading this (and did not have a
vested interest in one platform...), the last thing I'd want, is to go
through the trouble of migrating, only to find out 5 key things we need are
missing. *Zero research was done* on the available tools out there and how
they stack with Transifex. Here are examples of research done by other
projects which came across my attention: One
<http://www.worddelights.com/wp-content/uploads/2013/07/developer-side-com...
, Two
<https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095...
.
Ask the Transifex team itself to tell us how they compare to the other
platforms on all key areas. Cover solutions like Pootle which are developed
in a very open matter. Put in a spreadsheet and compare thoroughly.
This is responsible project management 101.
*ZANATA*
Those who have been around a while saw the Zanata push from the Red Hat
teams coming with mathematical precision. Even when Transifex was being
fully developed as open source, Red Hat decided to develop Zanata in
parallel instead of investing in Transifex. This has always struck me as
mind-boggling, given that Transifex was born in Fedora's arms and quickly
became the most popular open-source localization platform.
It is all in good spirit and competition is good. I am holding no grudge
against Zanata. In fact, the Zanata team's efforts to grab Fedora in the
past has pushed Tx to innovate fast.
Having said this...
In terms of Freedom, out of all the localization platforms out there, and
given what I've seen the past years, Zanata is developed in one of the
least open ways. Which open-source projects are using Zanata? On zanata.org I
can see a bunch of test projects, a few Red Hat documentation ones and JBoss
<https://translate.jboss.org/> (also Red Hat's). Which other projects have
installed their own Zanata server and how many words are they translating?
*Pootle is a much more openly developed and widely accepted platform*. The
leads (Dwayne and Friedel) are true open-sourcers, their team is presenting
in many major open-source conferences, they're trusted by many large
open-source projects
<http://translate.sourceforge.net/wiki/pootle/live_servers> (Mozilla, Open
Office), proprietary ones (Evernote, Grooveshark, Rdio) and their feature
list <http://pootle.translatehouse.org/discover.html> is amazing. At FOSDEM
I'll go out for drinks with Friedel.
When there are tools like Pootle out there, why on Earth would Fedora even
consider Zanata? *Where is the research and comparison between the options
we have?*
*TRANSIFEX*
Transifex has 20+ people working full-time on the platform. A big chunk of
our time is invested on open-source, community projects
<https://www.transifex.com/customers/open-source/>;. There are projects on
Tx with as many as 1 Billion words being translated by 14.000 people. Joomla
<https://www.dropbox.com/s/tnaypyaylxnausr/Screenshot%202014-07-17%2013.11...
has
2.7K translators contributing on 250 projects.
If the goal is to have a *vibrant and successful Fedora Localization
Project*, then there are so many things to be done which make the "which
tool" discussion, quite frankly, stupid. Here are a couple:
- Use Transifex's Reports
<https://www.dropbox.com/s/o4htl010ieo38iw/Screenshot%202014-07-17%2012.40...
to constantly recognize our most active translators. Send them a t-shirt or
even simply mention them in the release notes.
- Nurture teams
<https://www.dropbox.com/s/3dtubts36oxhk1q/Screenshot%202014-07-17%2012.46...
by identifying inactive members and refreshing them.
- Help community members prioritize
<https://www.dropbox.com/s/5xbmbc2m1elmcva/Screenshot%202014-07-17%2012.49...
which projects to translate first and remove old content.
Do we want a successful community L10n project? These are the things we
should be discussing. And these are some of the things the Transifex team
is investing on. "What does the roadmap look like" is a key question for
the research on which tool to choose (which never happened).
*ENDING THOUGHTS*
As a Fedora contributor, I'm expecting a discussion for such an important
topic to have higher responsibility than the one I've seen so far. This is
an extremely important topic which has no place for hastiness or egos.
I'd be happy to help and wear my Fedora hat.
-d
--
Dimitris Glezos
Founder & CEO, Transifex
https://www.transifex.com/
7:43 a.m.
Hello Dmitris,
In one paragraph, you say that Fedora is free to move to another
platform, and in another, you list the extra features Transifex has that
can keep Fedora locked in.
Basically, it's exactly the same strategy that GMail/Drive is using, or
that Bitkeeper used in the past...
You can check-out any time you like,
but you can never leave!
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.
Your arguments that Zanata might not be the best solution are valid.
(Though your own "What does the roadmap look like" question might be
relevant here.)
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?
(Sorry for top-posting; my reply reads better in one block.)
On 07/17/2014 12:17 PM, Dimitris Glezos wrote:
Hey all,
I'll share some of my thoughts at this point.
*
*
*
*
*_GIST_*
* _Freedom_ is more than just access to a tarball. What kinds of
Freedom is Fedora enjoying and giving up by using a platform like
Transifex or GitHub?
o What is the _Board's position_ about using non-open-source but
open-friendly services? How much should we sacrifice to only run
open-source on our servers?
* Research thoroughly all possible solutions and find out what exactly
we'll be sacrificing and gaining. _Pootle_ is much more trusted than
Zanata.
* Ask all key Fedora L10n people. Past and current.
* Any switch should be led by a technical Fedora localization person.
* The goal should be to make Fedora L10n a successful project. The
tools are just tools. The most important community features in
Transifex have not been used.
*_BACKGROUND_*
My contributions to Fedora nowadays are limited to supporting the L10n
project with our Transifex instance. I used to be a member of the Fedora
Board in the past. I see there's still the title "Fedora Localization
Lead" next to my name, but I suppose that's mostly because no one else
took the role. Today I basically make sure the community has what they
need from Transifex. I trust Piotr Drąg (raven) for any L10n leadership
questions I have.
Today a decision is being brewed on the basis that Transifex is not
open-source. As I mentioned, this is a discussion which needed to
happen. But I find the way it's being discussed disappointing to all the
years of hard work many individuals have put to establish a successful
L10n platform for Fedora (including my own). Many people in Fedora (and
Transifex) have _invested /*man years*/ to make this work_. We haven't
even discussed "what are the key things we need from our L10n platform"?
Following are my thoughts. I'm writing these with an effort to wear my
Fedora L10n hat as much as possible. But the POV does also include my
roles as Transifex's CEO, Fedora's Localization Infrastructure Lead for
the past 6 years, and as one of the most experienced people on
open-source localization.
*_ON FREEDOM_*
When I was young I was looking at freedom in a different way. I was more
an open source zealot than today. I cared mostly about openness of the
code. It didn't matter if there was only one engineer hacking on the
code. What mattered was the license and little more.
Gradually I started realizing one of the reasons I loved Fedora was that
it valued highly quality and community participation. It valued
relationships, productivity, happiness, innovation. We valued
meritocracy more than democracy. Succeeding as a distributions was more
than just having the sources of packages.
_I'm not a fan of the spin put on Freedom in this discussion_. Fedora is
free to use Transifex forever. It's free to export all data at any point
(including all past translations and all the history of the translations
so far) to move to another platform. And it was free to use real people
from our team working on improving the platform constantly and adding
new features. I've met a lot of people in Fedora. The smartest ones knew
very well that _Freedom is not a one-colored attribute_.
*_MIGRATING_*
Migrating from one platform to another will have _major costs_. I led
the original migration from Elvis
<http://fedoraproject.org/wiki/Archive:L10N/Tools/Plans> to Tx. It
required many meetings with stakeholders, research, experiments. In the
end, _it costed us more than half our translators_.
Assuming the Freedom discussion is resolved and the benefits of the
migration outweigh the costs. If I were leading this (and did not have a
vested interest in one platform...), the last thing I'd want, is to go
through the trouble of migrating, only to find out 5 key things we need
are missing. _Zero research was done_ on the available tools out there
and how they stack with Transifex. Here are examples of research done by
other projects which came across my attention: One
<http://www.worddelights.com/wp-content/uploads/2013/07/developer-side-com...;,
Two
<https://docs.google.com/spreadsheet/ccc?key=0Aqevw3Q-ErDUdFgzT3VNVXQxd095...;.
Ask the Transifex team itself to tell us how they compare to the other
platforms on all key areas. Cover solutions like Pootle which are
developed in a very open matter. Put in a spreadsheet and compare
thoroughly.
This is responsible project management 101.
*_ZANATA_*
Those who have been around a while saw the Zanata push from the Red Hat
teams coming with mathematical precision. Even when Transifex was being
fully developed as open source, Red Hat decided to develop Zanata in
parallel instead of investing in Transifex. This has always struck me as
mind-boggling, given that Transifex was born in Fedora's arms and
quickly became the most popular open-source localization platform.
It is all in good spirit and competition is good. I am holding no grudge
against Zanata. In fact, the Zanata team's efforts to grab Fedora in the
past has pushed Tx to innovate fast.
Having said this...
In terms of Freedom, out of all the localization platforms out there,
and given what I've seen the past years, Zanata is developed in one of
the least open ways. Which open-source projects are using Zanata? On
zanata.org <http://zanata.org/> I can see a bunch of test projects, a
few Red Hat documentation ones and JBoss
<https://translate.jboss.org/> (also Red Hat's). Which other projects
have installed their own Zanata server and how many words are they
translating?
_Pootle is a much more openly developed and widely accepted platform_.
The leads (Dwayne and Friedel) are true open-sourcers, their team is
presenting in many major open-source conferences, they're trusted by
many large open-source projects
<http://translate.sourceforge.net/wiki/pootle/live_servers> (Mozilla,
Open Office), proprietary ones (Evernote, Grooveshark, Rdio) and their
feature list <http://pootle.translatehouse.org/discover.html> is
amazing. At FOSDEM I'll go out for drinks with Friedel.
When there are tools like Pootle out there, why on Earth would Fedora
even consider Zanata? _Where is the research and comparison between the
options we have?_
*_TRANSIFEX_*
Transifex has 20+ people working full-time on the platform. A big chunk
of our time is invested on open-source, community projects
<https://www.transifex.com/customers/open-source/>;. There are projects
on Tx with as many as 1 Billion words being translated by 14.000 people.
Joomla
<https://www.dropbox.com/s/tnaypyaylxnausr/Screenshot%202014-07-17%2013.11...
has
2.7K translators contributing on 250 projects.
If the goal is to have a _vibrant and successful Fedora Localization
Project_, then there are so many things to be done which make the "which
tool" discussion, quite frankly, stupid. Here are a couple:
* Use Transifex's Reports
<https://www.dropbox.com/s/o4htl010ieo38iw/Screenshot%202014-07-17%2012.40...
to constantly recognize our most active translators. Send them a
t-shirt or even simply mention them in the release notes.
* Nurture teams
<https://www.dropbox.com/s/3dtubts36oxhk1q/Screenshot%202014-07-17%2012.46...
by identifying inactive members and refreshing them.
* Help community members prioritize
<https://www.dropbox.com/s/5xbmbc2m1elmcva/Screenshot%202014-07-17%2012.49...
which projects to translate first and remove old content.
Do we want a successful community L10n project? These are the things we
should be discussing. And these are some of the things the Transifex
team is investing on. "What does the roadmap look like" is a key
question for the research on which tool to choose (which never happened).
*_ENDING THOUGHTS_*
As a Fedora contributor, I'm expecting a discussion for such an
important topic to have higher responsibility than the one I've seen so
far. This is an extremely important topic which has no place for
hastiness or egos.
I'd be happy to help and wear my Fedora hat.
-d
--
Petr³
4:52 p.m.
2014-07-17 12:17 GMT+02:00 Dimitris Glezos <glezos(a)transifex.com>:
Hey all,
I'll share some of my thoughts at this point.
GIST
Freedom is more than just access to a tarball. What kinds of Freedom is
Fedora enjoying and giving up by using a platform like Transifex or GitHub?
What is the Board's position about using non-open-source but open-friendly
services? How much should we sacrifice to only run open-source on our
servers?
Research thoroughly all possible solutions and find out what exactly we'll
be sacrificing and gaining. Pootle is much more trusted than Zanata.
Ask all key Fedora L10n people. Past and current.
Any switch should be led by a technical Fedora localization person.
The goal should be to make Fedora L10n a successful project. The tools are
just tools. The most important community features in Transifex have not been
used.
[snip]
--
Dimitris Glezos
Founder & CEO, Transifex
https://www.transifex.com/
Dimitris,
we need to be consistent IMHO, if one of our foundations is FREEDOM we
can't use non-free tools, or at least we should not use them if we
have alternatives. As a mentor I'd feel bad telling people about
Fedora's values and knowing at the same time the Project itself is not
consistent with exactly these values. It's the same discussion we had
for 3d party repositories, but we should focus on this single topic.
Zanata actually is an alternative, probably not on the same level as
TX, but anyway, I'd feel better using Zanata knowing we are respecting
or 4 foundations, than staying on a proprietary tool.
Best regards.
--
Robert Mayr
(robyduck)
9 p.m.
----- Original Message -----
ZANATA
In terms of Freedom, out of all the localization platforms out there, and given what
I've seen the past years, Zanata is developed in one of the least open ways. Which
open-source projects are using Zanata? On zanata.org I can see a bunch of test projects, a
few Red Hat documentation ones and JBoss (also Red Hat's). Which other projects have
installed their own Zanata server and how many words are they translating?
I wonder why you say "least open ways"
Zanata is open source, and license under LGPLv2+.
The source code is visible in github, and patches and pull requests are welcome.
Bugs and enhancement requests can be filed and tracked in Red Hat Bugzilla, which is
public facing.
You can even use your FAS account, Google, Yahoo, and other open ID to login.
Once you have registered, you can create projects freely, and that's why you see lots
of test projects.
<blockquote>
Pootle is a much more openly developed and widely accepted platform . The leads (Dwayne
and Friedel) are true open-sourcers, their team is presenting in many major open-source
conferences, they're trusted by many large open-source projects (Mozilla, Open
Office), proprietary ones (Evernote, Grooveshark, Rdio) and their feature list is amazing.
At FOSDEM I'll go out for drinks with Friedel.
When there are tools like Pootle out there, why on Earth would Fedora even consider
Zanata? Where is the research and comparison between the options we have?
</blockquote>
Zanata offers online realtime multiple users collaborate, Pootle does not.
Zanata offers FAS, JBossSSO, Google, Yahoo, and OpenID login; but Pootle does not.
With pootle, it seems like each organization need to create its own pootle instance.
With Zanata, you can either setup your own server, or use our public instances, where the
translations can be shared by other projects and organizations.
--
<blockquote>
Dimitris Glezos
Founder & CEO, Transifex
https://www.transifex.com/
--
trans mailing list
trans(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans
</blockquote>
--
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dchen(a)redhat.com
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com
Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
5:55 a.m.
On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori(a)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/
6:30 a.m.
Fri, 18 Jul 2014 13:55:45 +0300 було написано Dimitris Glezos
<glezos(a)transifex.com>:
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.
Hi,
Below is just my point of view, not a universal truth.
For the manager of free projects (regardless to the "free-as-a-beer" or
"free, as a speech") all above features have a little sense. The free
projects hardly suffers form the cache floe optimization problems, neither
they suffer from ability to prepare right bills.
As for me, it does not matter how much strings were translated, the main
purpose of TMS is just to spare developers and translators time.
Most of web-based TMS are failed to do so. Overcomplicated interfaces
(Wordbee), general Python slowness and attempts to use all modern web
features (Pootle, current Transifex), constant database failures and slow
imports (Rosetta). It takes some precious time to jump from one message to
another, to see the fuzzy match, to push the translation, and to pull it
from server. The thing that should simplify the life just wants to be
everything. To be honest, I do not want to see the graphs or even the
estimated time to complete the translation (Zanata), I just want the
translation to be done right in time, to be precise and free from mistakes
for the minimum waste of time.
Sometimes simple interfaces to the translation repos (Damned Lies, KDE
SVN, TP) are twice more effective in combination with offline editor (e.g.
Lokalize with TM and fuzzy matching), than nice slow web interfaces
(Transifex, Pootle, Wordbee) and ability to translated from your mobile
phone. ;)
So the TMS for me is just a simple interface to VCS, nothing more. And
Zanata is an effective enough interface.
Just my 2 cents.
Best regards,
Yuri
P.S. Just for the background, I have used most of mentioned platforms
(Zanata, Pootle, Transifex, Translate wiki extension, Rosetta) and Wordbee
proprietary TMS. And I have translated many FOSS (KDE, GNOME, TP
templates, Inkscape, Scilab, etc.) and some proprietary products (mainly
Opera ASA products).
7:33 a.m.
On 07/18/2014 12:55 PM, Dimitris Glezos wrote:
On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin
<pviktori(a)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.
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
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).
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
external DB/repository.
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
only-translated etc).
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.
--
Petr³
9:38 a.m.
May I suggest a different way of working?
I would like to suggest that translation works best with teams of two. I worked for a
long while in a Canadian company (name on request) that had to rapidly produce correct
grammar. and topic flow of translated text. Languages included French, English, Spanish,
Turkish and some others.
The original multi-page text was broken down into sections of one to two page sections.
From the original text, a translator / editor pair of people were chosen for the target
language and for a section.
We used a word processor (you may use libreoffice) and the markup /comments facility that
is integral to the wordprocessor product. The translator produced the first cut, the
editor read, corrected, commented and reorganized same using the tools within the
wordprocessor. The translator could accept, or refuse the editor's changes. The
document was passed back and forth. With one or two iterations, the translated section
was accepted. Fait-accompli. Spell checking was included as well as some validation of
sentence construction
There are many users who would want to work on translation. Divide the work into
deliverable sections. Assign pairs of individuals to a deliverable section. Don't
forget to assign a "Must complete by" date.
The company mentioned edits the text against the original English version. Consideration
is given to figures of speech and slang, in that these do not always translate well. As
well, the English had to be targeted at a high-school level, or anticipated audience.
There are full time translator specialists for each language in the above mentioned
organization. They get good clean publishable output.
Regards
Leslie
Mr. Leslie Satenstein
________________________________
From: Dimitris Glezos <glezos(a)transifex.com>
To: Fedora Translation Project List <trans(a)lists.fedoraproject.org>
Sent: Friday, July 18, 2014 6:55 AM
Subject: Re: On Fedora's Localization platform
On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori(a)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/
--
trans mailing list
trans(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans
9:35 p.m.
Re-posted.
Somewhat I could not receive this post properly. Same problem happened
to the other post at trans-ja. Both were sent from yahoo mail. The
Japanese member changed his registered mail address to avoid the
problem. Could someone can confirm if this happens to you?
noriko
(2014年07月19日 00:38), Leslie S Satenstein wrote:
May I suggest a different way of working?
I would like to suggest that translation works best with teams of two.
I worked for a long while in a Canadian company (name on request) that
had to rapidly produce correct grammar. and topic flow of translated
text. Languages included French, English, Spanish, Turkish and some others.
The original multi-page text was broken down into sections of one to two
page sections.
From the original text, a translator / editor pair of people were
chosen for the target language and for a section.
We used a word processor (you may use libreoffice) and the markup
/comments facility that is integral to the wordprocessor product. The
translator produced the first cut, the editor read, corrected, commented
and reorganized same using the tools within the wordprocessor. The
translator could accept, or refuse the editor's changes. The document
was passed back and forth. With one or two iterations, the translated
section was accepted. Fait-accompli. Spell checking was included as
well as some validation of sentence construction
There are many users who would want to work on translation. Divide the
work into deliverable sections. Assign pairs of individuals to a
deliverable section. Don't forget to assign a "Must complete by" date.
The company mentioned edits the text against the original English
version. Consideration is given to figures of speech and slang, in that
these do not always translate well. As well, the English had to be
targeted at a high-school level, or anticipated audience.
There are full time translator specialists for each language in the
above mentioned organization. They get good clean publishable output.
Regards
*
Leslie
*
*Mr. Leslie Satenstein*
**
**
------------------------------------------------------------------------
*From:* Dimitris Glezos <glezos(a)transifex.com>
*To:* Fedora Translation Project List <trans(a)lists.fedoraproject.org>
*Sent:* Friday, July 18, 2014 6:55 AM
*Subject:* Re: On Fedora's Localization platform
On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori(a)redhat.com
<mailto:pviktori@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/
--
trans mailing list
trans(a)lists.fedoraproject.org <mailto:trans@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/trans
--
trans mailing list
trans(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans
12:33 a.m.
написане Wed, 23 Jul 2014 05:35:08 +0300, Noriko Mizumoto
<noriko(a)fedoraproject.org>:
Re-posted.
Somewhat I could not receive this post properly. Same problem happened
to the other post at trans-ja. Both were sent from yahoo mail. The
Japanese member changed his registered mail address to avoid the
problem. Could someone can confirm if this happens to you?
noriko
Hi,
http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-br...
Hope this helps to understand the problem.
Best regards,
Yuri
(2014年07月19日 00:38), Leslie S Satenstein wrote:
> May I suggest a different way of working?
>
> I would like to suggest that translation works best with teams of two.
> I worked for a long while in a Canadian company (name on request) that
> had to rapidly produce correct grammar. and topic flow of translated
> text. Languages included French, English, Spanish, Turkish and some
> others.
>
> The original multi-page text was broken down into sections of one to two
> page sections.
>
> From the original text, a translator / editor pair of people were
> chosen for the target language and for a section.
>
> We used a word processor (you may use libreoffice) and the markup
> /comments facility that is integral to the wordprocessor product. The
> translator produced the first cut, the editor read, corrected, commented
> and reorganized same using the tools within the wordprocessor. The
> translator could accept, or refuse the editor's changes. The document
> was passed back and forth. With one or two iterations, the translated
> section was accepted. Fait-accompli. Spell checking was included as
> well as some validation of sentence construction
>
> There are many users who would want to work on translation. Divide the
> work into deliverable sections. Assign pairs of individuals to a
> deliverable section. Don't forget to assign a "Must complete by"
date.
>
> The company mentioned edits the text against the original English
> version. Consideration is given to figures of speech and slang, in that
> these do not always translate well. As well, the English had to be
> targeted at a high-school level, or anticipated audience.
>
> There are full time translator specialists for each language in the
> above mentioned organization. They get good clean publishable output.
>
>
> Regards
> *
> Leslie
> *
> *Mr. Leslie Satenstein*
> **
> **
>
> ------------------------------------------------------------------------
> *From:* Dimitris Glezos <glezos(a)transifex.com>
> *To:* Fedora Translation Project List
> <trans(a)lists.fedoraproject.org>
> *Sent:* Friday, July 18, 2014 6:55 AM
> *Subject:* Re: On Fedora's Localization platform
>
> On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori(a)redhat.com
> <mailto:pviktori@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/
> --
> trans mailing list
> trans(a)lists.fedoraproject.org <mailto:trans@lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/trans
>
>
>
> --
> trans mailing list
> trans(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/trans
>
--
trans mailing list
trans(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans
12:51 a.m.
(2014年07月23日 15:33), Yuri Chornoivan wrote:
написане Wed, 23 Jul 2014 05:35:08 +0300, Noriko Mizumoto
<noriko(a)fedoraproject.org>:
> Re-posted.
> Somewhat I could not receive this post properly. Same problem happened
> to the other post at trans-ja. Both were sent from yahoo mail. The
> Japanese member changed his registered mail address to avoid the
> problem. Could someone can confirm if this happens to you?
>
> noriko
Hi,
http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-br...
Hope this helps to understand the problem.
Best regards,
Yuri
OH! Yuri, thank you so much~~
noriko
>
> (2014年07月19日 00:38), Leslie S Satenstein wrote:
>> May I suggest a different way of working?
>>
>> I would like to suggest that translation works best with teams of two.
>> I worked for a long while in a Canadian company (name on request) that
>> had to rapidly produce correct grammar. and topic flow of translated
>> text. Languages included French, English, Spanish, Turkish and some
>> others.
>>
>> The original multi-page text was broken down into sections of one to two
>> page sections.
>>
>> From the original text, a translator / editor pair of people were
>> chosen for the target language and for a section.
>>
>> We used a word processor (you may use libreoffice) and the markup
>> /comments facility that is integral to the wordprocessor product. The
>> translator produced the first cut, the editor read, corrected, commented
>> and reorganized same using the tools within the wordprocessor. The
>> translator could accept, or refuse the editor's changes. The document
>> was passed back and forth. With one or two iterations, the translated
>> section was accepted. Fait-accompli. Spell checking was included as
>> well as some validation of sentence construction
>>
>> There are many users who would want to work on translation. Divide the
>> work into deliverable sections. Assign pairs of individuals to a
>> deliverable section. Don't forget to assign a "Must complete by"
date.
>>
>> The company mentioned edits the text against the original English
>> version. Consideration is given to figures of speech and slang, in that
>> these do not always translate well. As well, the English had to be
>> targeted at a high-school level, or anticipated audience.
>>
>> There are full time translator specialists for each language in the
>> above mentioned organization. They get good clean publishable output.
>>
>>
>> Regards
>> *
>> Leslie
>> *
>> *Mr. Leslie Satenstein*
>> **
>> **
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Dimitris Glezos <glezos(a)transifex.com>
>> *To:* Fedora Translation Project List
>> <trans(a)lists.fedoraproject.org>
>> *Sent:* Friday, July 18, 2014 6:55 AM
>> *Subject:* Re: On Fedora's Localization platform
>>
>> On Thu, Jul 17, 2014 at 3:43 PM, Petr Viktorin <pviktori(a)redhat.com
>> <mailto:pviktori@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/
>> --
>> trans mailing list
>> trans(a)lists.fedoraproject.org <mailto:trans@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/listinfo/trans
>>
>>
>>
>> --
>> trans mailing list
>> trans(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/trans
>>
>
> --
> trans mailing list
> trans(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/trans
3563
days inactive
3569
days old
10 comments
7 participants
participants (7)
-
Dimitris Glezos -
Ding Yi Chen -
Leslie S Satenstein -
Noriko Mizumoto -
Petr Viktorin -
Robert Mayr -
Yuri Chornoivan