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

List:       kde-i18n-doc
Subject:    Translation Methods comparsion
From:       Leon Feng <rainofchaos () gmail ! com>
Date:       2013-03-22 3:16:29
Message-ID: CAO85cbjzrkJQ=F+c6PS9rnfx9jMN45CasfSaKSTk51wzo39nHg () mail ! gmail ! com
[Download RAW message or body]

I am suprised to see KDE may use it for GUI translation in translationWiki
newsletter. If there will exist a web translation interface, I am afraid
the best choice will not be translatewiki but should be Transifex. Here is
my experience about Launchpad /transifex/ Localize/ translatewiki to backup
this choice.

First is Launchpad. Use it at around (2006~2008). Top translator of zh_CN
team at that time.
Pro: Easy to start. So the contributor base is the largest at that time.
Con: Very hard to make translation upstream. Most of the rot in Ubuntu.

Lokalize: (2008~now)
To make my KDE GUI translation upstream, I get involved with kde-cn and
lokalize. And I get my KDE commit access shortly.
Pro: Effiency - Offline Lokalize is much faster than web interface. In my
experence, it  at least cut the time half. So I stop working on Launchpad
quickly. Translation memory avoid duplicate work. The most import part is
it make translation consistent which is more import in the GUI than Wiki
text.
Con: PO file is hard to work with. svn account and a minimal skill is
needed. This did disappoint some translators in kde-cn and some left.

Translatewiki: (2010~now) Mostly in Userbase and Techbase.
Pro: Specially optimized for Wiki work flow. Easy to keep text sync with
English.
Con: Make the original English page hard to edit. Compare to Arch Wiki,
Userbase and Techbase have a much much smaller user edits. I blame its ugly
syntex. I myself spend almost 1 years before I dare to edit the page with
"<!--T:6-->" marking :)

Transifex: I joined many projects but do little translation. Because when I
check my dash board, usually all the work is already done by someone else,
in very good quality.
Pro: Easy to start as Launchpad. Easy to make work upstream. Good svn git
integration.
Con: Need time to maintain, especially for project as large as KDE.

Conclusion:
I will keep using Lokalize in the future. But sometime I ask myself, will I
enter KDE translation without experience in Launchpad when I am a novice.
The answer is probably no. Have a web access to KDE GUI translation will
increase our contributor base. Then we can guide them to use Lokalize for
quality.

TranslateWiki is absolutely the choice of Wiki translation. But I question
its role in GUI translation. Po and  wiki have different, po files should
be sync with svn repo everyday or at least every week. Believe me, it is
very hard work. Suggestion: Let one l18n team to do a test run to defeat my
concern above :)

Feng Chao

[Attachment #3 (text/html)]

I am suprised to see KDE may use it for GUI translation in translationWiki =
newsletter.=A0If there will exist a web translation interface, I am afraid =
the best choice will not be translatewiki but should be Transifex.=A0Here i=
s my experience about Launchpad /transifex/ Localize/ translatewiki to back=
up this choice.=A0<div>

<br></div><div>First is Launchpad. Use it at around (2006~2008). Top transl=
ator of zh_CN team at that time.</div><div>Pro: Easy to start. So the contr=
ibutor base is the largest at that time.</div><div>Con: Very hard to make t=
ranslation upstream. Most of the rot in Ubuntu.=A0</div>

<div><br></div><div>Lokalize: (2008~now)=A0</div><div>To make my KDE GUI tr=
anslation upstream, I get involved with kde-cn and lokalize. And I get my K=
DE commit access shortly.=A0</div><div>Pro: Effiency - Offline Lokalize is =
much faster than web interface. In my experence, it =A0at least cut the tim=
e half. So I stop working on Launchpad quickly. Translation memory avoid du=
plicate work. The most import part is it make translation consistent which =
is more import in the GUI than Wiki text.</div>

<div>Con: PO file is hard to work with. svn account and a minimal skill is =
needed. This did disappoint some translators in kde-cn and some left.=A0</d=
iv><div><br></div><div>Translatewiki: (2010~now) Mostly in Userbase and Tec=
hbase.=A0</div>

<div>Pro: Specially optimized for Wiki work flow. Easy to keep text sync wi=
th English.</div><div>Con: Make the original English page hard to edit. Com=
pare to Arch Wiki, Userbase and Techbase have a much much smaller user edit=
s. I blame its ugly syntex. I myself spend almost 1 years before I dare to =
edit the page with &quot;&lt;!--T:6--&gt;&quot; marking :)</div>

<div><br></div><div>Transifex: I joined many projects but do little transla=
tion. Because when I check my dash board, usually all the work is already d=
one by someone else, in very good quality.</div><div>Pro: Easy to start as =
Launchpad. Easy to make work upstream. Good svn git integration.</div>

<div>Con: Need time to maintain, especially for project as large as KDE.=A0=
</div><div><br></div><div>Conclusion:</div><div>I will keep using Lokalize =
in the future. But sometime I ask myself, will I enter KDE translation with=
out experience in Launchpad when I am a novice. The answer is probably no. =
Have a web access to KDE GUI translation will increase our contributor base=
. Then we can guide them to use Lokalize for quality.=A0</div>

<div><br></div><div>TranslateWiki is absolutely the choice of Wiki translat=
ion. But I question its role in GUI translation. Po and =A0wiki have differ=
ent, po files should be sync with svn repo everyday or at least every week.=
 Believe me, it is very hard work. Suggestion: Let one l18n team to do a te=
st run to defeat my concern above :)</div>

<div><br></div><div>Feng Chao</div>


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