On Fedora's Localization platform

Fri Jul 18 14:38:16 UTC 2014

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 at transifex.com>
>To: Fedora Translation Project List <trans at 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 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/
>--
>trans mailing list
>trans at lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/trans
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/trans/attachments/20140718/d5ca2dd2/attachment.html>