[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Translation Methods comparsion
From:       Leon Feng <rainofchaos () gmail ! com>
Date:       2013-04-01 12:10:40
Message-ID: CAO85cbg2SUO5h437BBWxx71TGb5XC4_OXFcL9V_97cPa_xPnuA () mail ! gmail ! com
[Download RAW message or body]

2013/4/1 Federico Leva (Nemo) <nemowiki@gmail.com>:
> Leon Feng, 01/04/2013 04:43:
>
>> Ok, maybe I overestimate the work need to be done. Question:
>> 1. Who will handle the sync && merge between Translatewiki and KDE
>> repo. How often ?
>
>
> Who: someone in translatewiki.net staff. How often: you decide, usually
> every week or so; MediaWiki is updated every day because localisation
> updates go live on Wikimedia projects within 24/48 hours (Raymond, the
> maintainer, says it takes about 15 min per export of all the ~300
> languages).

Right now MediaWiki has 2,878 messages. KDE has: 209590 messages. So
the message size is 100 times larger.
Could you give us a estimation of how long will it take based on your
experience?

>
>
>> 2. If a po on both side are updated. Which one will translatewiki take?
>> Hint: Take KDE repo one, the translatewiki user will be angry that
>> their work is lost. vice versa. Launchpad has a third "upstream" flag
>> to handle it. AFAIK, translatewiki lack the same ability.
>
>
> I've already answered this. As for the flag, translations can be marked a=
s
> in need of update/checking.
>
> Federico Leva (Nemo), 22/03/2013 19:10:
>>      On "However this merge is a bit difficult": it's not with
>> translatewiki.net. The system takes care of all merge and commit
>> activity in the translators' stead. Even if for some reason someone
>> commits translations directly to the CVS =96 instead of submitting the
>> files from offline translation via translatewiki.net as possible and
>> recommended[1] =96, conflicts are handled by the person responsible for
>> the exports with Translate's scripts.[2] Again, as Niklas said, each
>> language team would decide to join translatewiki.net individually, and
>> while doing so could even decide to automatically get any conflicting
>> translation thrown in the trashbin when coming from it (not nice, but
>> possible). [...]

As discussed before, we could/would not stop using lokalize because it
is much more efficient than translatewiki.
Message merge is exactly the maintainance burden I said before.

>>
>> [1]
>>
>> <https://www.mediawiki.org/wiki/Help:Extension:Translate/Off-line_transl=
ation>.
>>
>> [2]
>> <https://www.mediawiki.org/wiki/Help:Extension:Translate/Group_managemen=
t>
>> (stub but no real need to care, translatewiki.net staff does it).
>
> And your last point:
>
>
>> Other than merely discussion, let us get the work done. If anyone
>> setup what ever  system, I am glad to try out and give feedback.
>
>
> Sure, trying is the only way to fully understand; and Niklas wants to sta=
rt
> some pilots in the first place (if there's some interest). Can you discus=
s
> this with your language team and write on
> https://translatewiki.net/wiki/Translating:KDE if you're available for a
> pilot?
> You can also subscribe and try translation of other software, it takes ju=
st
> a few minutes: https://translatewiki.net/wiki/Special:FirstSteps
>
> Sankarshan Mukhopadhyay, 01/04/2013 05:49:
>
>> On Mon, Apr 1, 2013 at 8:13 AM, Leon Feng <rainofchaos@gmail.com> wrote:
>>> 1. Who will handle the sync && merge between Translatewiki and KDE
>>> repo. How often ?
>>> 2. If a po on both side are updated. Which one will translatewiki take?
>>
>> I'm hoping that the TranslateWiki.net folks would be able to answer
>> both queries.
>
> So able that I had already answered 10 days ago. :D
>
>
>> On a related note, the first one would probably require
>> a small group (ie. more than one) person with appropriate privileges
>> to keep an eye out on any errors in the automated sync-merge. It
>> should be transparent to the users of the systems.
>
> No. Translatewiki.net is designed so that translators mustn't worry about
> such technicalities and anything but translation.
> Each language team can decide to always prefer translations from one or t=
he
> other side, or to rely on all translators switching to translatewiki.net
> (given that no language will land there without language team agreement
> anyway), or to import conflicting translations in the VCS as "fuzzy"
> messages in need of check by any translator directly on the wiki... but
> nothing will ever require wizardry on translators' side.
> (However, I hope KDE teams would reach an agreement on the option to foll=
ow
> because I'm not so sure of the "each language" above,  ;-) and I'm not su=
re
> how the fuzzy on import currently works in detail.)

And do you familiar with raw po files? How would you handle this work flow:

1. import this empty message to translatewiki:
#: ..\..\..\abc.cpp:100
msgid "Editing post"
msgstr ""

2. Message translate and export to:
#: ..\..\..\admin\b2edit.php:100
msgid "Editing post"
msgstr "Edition d'un article"

3. When submit translated po, the file in the svn repo changed to:
#: ..\..\..\admin\b2edit.php:99
msgid "Editing post"
msgstr "Edition d'un article"

Note only the line number changes, but it is actually a merge conflict
svn itself can not handle.

Right now in zh_CN team we use the powerful lokalize to handle this issue.
Do you have a existing method to automate this task?

>
> Nemo
[prev in list] [next in list] [prev in thread] [next in thread]