faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Translation
by Rinse on Friday 24/Jun/2005, @04:49
|
Contributing is still as easy as it was 3 years ago, and a lot easier then it was 5 years ago. (5 years ago, you had to use an editor, like kwrite or nedit, nowadays you can use special po-editors, webbased interfaces, translation memories, etc. etc...)
The difference between the years is that the amount of strings that need to be translated is a lot larger.
Statistics don't tell the whole story about the status of a translation team. Some teams decide not to translate all available software in cvs, but to maintain only thos apps that make sense to them. Statisticly those teams came to a standstil, while in reality they are continuing improving their current translations..
Also, looking in 'stable' does not give you the correct picture. For example, the Dutch team is translating the docs in 'trunk', not in 'stable'. And now that extragear can use branches, third party applications will probably appear in the 'stable' stats of i18n.kde.org. Not every team is translating third party apps, so the stats will go down...
Besides, whatever infrastructure we will use, translating documentation and applications will always mean that you have to translate the English strings, and that is a very time consuming task...
What the translation teams need is people who are willing to spent some of their precious time translating the gui and docs to their language..
Rinse |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Translation
by Andre on Friday 24/Jun/2005, @13:00
|
What the wiki way showed us was: lower entrance barriers and the project will lift up. Wikipedia reached what the closed open contribution project Nupedia failed to reach. Translation is an easy task but it is not made easy.
- you have to contact the project and get involved
- you have to know what po and pot files are
- you have to get the right files.
- you need knowledge of KDE internals, SVN
Webbased tools for translations are of course a great contribution but currently third party.
There are today much more KDE users than 3 years ago. The translation infrastructure does not scale. It does not attract contributors. Community plattforms such as KDe-look or KDE-apps were also a great example what can be achieved whwn you lower entrance barriers.
|
[
Reply To This | View ]
|
Re: Translation
by ac on Friday 24/Jun/2005, @14:17
|
"The translation infrastructure does not scale."
While everything else you wrote is fine and dandy (and mostly bogus in KDE's case unless you are the first translator of your mother language) what's your proof for the above statement?
|
[
Reply To This | View ]
|
Re: Translation
by Andre on Friday 24/Jun/2005, @18:10
|
It does not scale means: A lot of new apps are added but the "low involvement" task translation does not adapt in a fast way. Even major KDE languages such as German are not 100% done in the stable branch. Note that there are many KDe users in Germany.
I know that some review is needed. But contributing is currently not an average joe task. Translations have still a serious lack. While programming and development in general becomes easiert the translation infrastructure was frozen in say 2002, regarded as good enough. i don't think it is.
|
[
Reply To This | View ]
|
Re: Translation
by Rinse on Saturday 25/Jun/2005, @00:39
|
Looking at the German stats, Except for kio_svn.po and some strings in spy.po their translation of the official KDE-modules is completed.
kio_svn.po was added after the release of kde 3.4.1 (afaik), so it's no wonder that one is untranslated. The german team has until july 17 to translate it :)
Looking at the stats of the german koffice, You will notice that krita, kplato and kivio are unfinished.
Both krita and kivio contain a lot of strings that need more than average knowledge of the subject to translate.
In those cases, the fact that they are po-files is not the barrier, but being familiar with the typ of application is.
I don't see how a wiki or other webbased solution can solve that.
One of the major issues that a wiki does not solve either is the quality of the translation in order of consistency with other parts of KDE. One can translate the hundreds of different colors in krita, or the hundreds of different stencils kivio by sucking them out of you thumb, but that would end up with a shamefull translation rather then a usefull translation.
Looking back at the Dutch translation of Krita, most of the color strings are left untranslated. But you won't see that in the stats, because we copied/pasted the English phrase to the translation. If the German team also decides not to translate the named colors, but does not copy them to the translation fields, then their stats would put them behind the Dutch team, while in real life they are not. (like i said earlier, stats don't tell the whole story)
|
[
Reply To This | View ]
|
Re: Translation
by Andre on Saturday 25/Jun/2005, @08:33
|
Forget about the stats. It is about the fact that in the current translation model translation is not the easy taks it is supposed to be.
And documentation is really worse than GUI. The team does not scale. The question is: how long will it last to translate 100%, is the change and new string expansion faster than what a translation team contributes.
We don't want a translation lag.
I understand pretty well that translation is not that easy, that it requires high skills.
It is more a recruitment issue. Open models are always superiour.
|
[
Reply To This | View ]
|
Re: Translation
by Rinse on Saturday 25/Jun/2005, @21:11
|
> It is about the fact that in the current translation model translation is not the easy taks it is supposed to be.
But why isn't it?
You don't come up with any reason of why the current model fails...
>I understand pretty well that translation is not that easy, that it requires high skills.
>It is more a recruitment issue
You won't reach more users with high skills by lowering the barier to join a team.
It is the opposite, to ensure that you get volunteers that are capable of doing the job right, you need to have some kind of tresshold.
|
[
Reply To This | View ]
|
Re: Translation
by Rinse on Saturday 25/Jun/2005, @00:11
|
<i>What the wiki way showed us was: lower entrance barriers and the project will lift up. </i>
Looking at wikipedia.org, most Dutch translations are incomplete or outdated.
With wiki, it is true that the initial translation is easier, because of low entrance etc, but keeping the files up to date compared to their English equivalents is much more a pain than keeping po-files up to date.
<i>you have to contact the project and get involved</i>
Not necessary, but in general a good idea.
<i>you have to know what po and pot files are</i>
You only need to know that your working with po-files, just like you need to know that you are working with doc-files when writing a letter in MS Word..
<i>you have to get the right files.</i>
which are available from i18n.kde.org, just click on the right file to download it.
Or use a webbased system like pootle to organise the translation project, you can't translate the wrong file with pootle :)
<i>you need knowledge of KDE internals, SVN</i>
It's alway nice to know what you are translating, so knowledge of kde is indeed necessary.
But SVN knowledge?
Why?
<i>
Webbased tools for translations are of course a great contribution but currently third party.
</i>
Not true, there are several GPL-based versions, like pootle and another one of which i forgot the name of (the nameless one is part of the kde project)
Also, Wiki is third party..
<i>
There are today much more KDE users than 3 years ago. The translation infrastructure does not scale. It does not attract contributors.
</i>
That is not true.
Looking at the Dutch project, while a few years ago translating was allmost a one man job, now about 10 people are translating the desktop, and especially the documentation has never been this far translated in the past (currently 70%)
<i>
Community platforms such as KDE-look or KDE-APS were also a great example what can be achieved when you lower entrance barriers.</i>
You can't compare kde-look and kde-apps with translating software.
Things like wiki sound nice, but it is not in any way sufficient for translating software or docbookbased helpfiles.
First, a wiki does not have a translation memory. Without a translating memory, you need far more translators to do the job.
For example, the documentation of digikam contains about 28458 words (tags not included). Translating that amount of words would take several months. But since most of the chapters of the digikam documentation are using the same layout, about 60% of the docs can be automaticly translated with a tool called kbabel. Besides errorprone copy&paste, I can't think of a way with wiki that a translator can automaticly translate files based on earlier work from other files.
Another benefit of using po-files for documentation translation is that you don't have to deal with most of the tags and elements found in docbook sources of the kde help files. And the tags that are left over can be filled in with a single keystroke in kbabel.
That is also something I don't expect to do using a wiki-based translation.
Third, small changes in the original docbook-files are easy to find without the use of a diff-application.
Just checkout the sections in the po-files that are marked as 'fuzzy'
New and changed English strings are automaticly integrated in the po-files, and the translator only has to startup a po-editor like kbabel, or surf on the net to pootle, and move from fuzzy/untranslated to fuzzy/untranslated with just a single mouseclick or keystroke.
And last but not least, most translation projects resides in countries that don't have the luxury of flat-fee broad band internet. Using a wiki as translation tool (or any other kind of webbased solution) would mean that they need to use a dialup-connection with the internet while translating, which would make translating quite an expensive job to do...
|
[
Reply To This | View ]
|
Re: Translation
by Andre on Saturday 25/Jun/2005, @08:46
|
"With wiki, it is true that the initial translation is easier, because of low entrance etc, but keeping the files up to date compared to their English equivalents is much more a pain than keeping po-files up to date."
This is a problem of diffs. English as a primary documentation source, when the english version is changed, the translation has to adapt.
Wikipedia articles are usually not translations, so this is different. More articles about the same topic.
With KDE documentation it is 99% direct translation with perhaps other wording. So a change in the english original triggers a possible change need in the derived document.
> Things like wiki sound nice, but it is not in any way sufficient for translating software or docbookbased helpfiles.
It is not about using a wiki. It is about doing it the wiki way. Linux Professional Institute used a succesful system to get translations of articles on their website.
t7e http://www.lpi.org/en/projects.html
|
[
Reply To This | View ]
|
Re: Translation
by Rinse on Saturday 25/Jun/2005, @21:15
|
>Wikipedia articles are usually not translations, so this is different. More articles about the same topic.
So you agree that a 'wiki' way of translating documents is not the option.
>It is not about using a wiki. It is about doing it the wiki way. Linux Professional Institute used a succesful system to get translations of articles on their website.
But this is not about websites or other 'instant publishing' mechanismen, we are talking about the translations applications and documents that have a release schedule, deadline, etc.
If your translation is finished, one day after the freeze, your translation is not included and won't be until the next release.
No wiki-kind of translation mechanism can avoid that.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|