On Fedora's Localization platform

Wed Jul 23 02:35:08 UTC 2014

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 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
>     <mailto: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 <mailto:trans at lists.fedoraproject.org>
>     https://admin.fedoraproject.org/mailman/listinfo/trans
>
>
>
> --
> trans mailing list
> trans at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/trans
>