On Fedora's Localization platform

Wed Jul 23 05:51:43 UTC 2014

(2014年07月23日 15:33), Yuri Chornoivan wrote:
> написане Wed, 23 Jul 2014 05:35:08 +0300, Noriko Mizumoto
> <noriko at 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-breaks-mailing-lists.html
>
>
> 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 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
>>>
>>
>> --
>> trans mailing list
>> trans at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/trans