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@transifex.com>
To: Fedora Translation Project List <trans@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@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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans