<br><br><div class="gmail_quote">2008/6/13 Danilo Šegan <<a href="mailto:danilo@canonical.com">danilo@canonical.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> As western Ubuntu translators we only have to translate a small subset<br>
> of packages, basically the ones written under the Ubuntu umbrella, and<br>
> the documentation. Furthermore we have to spot for import errors and<br>
> keep an eye on single missing or changed strings. What we want to avoid<br>
> is a brain split between upstream and Ubuntu translations. For this task<br>
> we only need a team of about 5 to 10 active translators, who are capable<br>
> and interested in polishing.<br>
<br>
</div>Indeed, this is something where we need better sync with upstream<br>
translations for it to be practical: i.e. as long as what you see in<br>
Launchpad are the latest translations from upstream, I don't see any<br>
problem with current Launchpad approach.  Of course, some minor UI<br>
improvements are to be done (like grouping packages into<br>
ubuntu-desktop, kubuntu-desktop,...), and we are planning on doing<br>
them, but it all takes time.</blockquote><div><br>Indeed. Regarding making e.g. ubuntu-desktop groupings, from my point of view, as a person the worries about Ubuntu-upstream contribution conflicts, it would be much more useful to have groupings based on the upstream locations of the package, say make a GNOME-group, KDE-group, XFCE-group, TP-group, LP-group and "Scattered upstream"-group. That would make it very much easier to explain to a newcomer what he should do to contribute to a speceific package depending on which group it is in.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> Furthermore it is also very time consuming to review and approve<br>

> suggestions. I don't see a real speedup compared to writing them on my<br>
> own. Especially since there is no way to provide feedback to the<br>
> translators in Rosetta. If there is no contact outside of Rosetta I have<br>
> to correct the same errors again and again.<br>
<br>
</div>I believe the lack of documentation is to blame here.  Reviewing<br>
suggestions would not speed you up short-term, but once you have<br>
reviewed enough of someone's translations and start considering him a<br>
good translator, you'd make him a reviewer as well, and then it would<br>
be two of you translating, and two of you reviewing.</blockquote><div><br>I disagree. I believe it is the process currently involved that is the principal source of the time used reviewing, reviewing _can_ be done in a manner that takes less time per string than you would use translating it your self, so getting more people to review would simply mean more people wasting time.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I.e. imagine sequence of uploads:<br>
<br>
 Last-Translator: Sascha<br>
 msgid "File" msgstr "Datei"<br>
<br>
 Last-Translator: Karl<br>
 msgid "File" msgstr "DDatei"<br>
<br>
 Last-Translator: Karl<br>
 msgid "File" msgstr "Datei"<br>
<br>
This may lead to a case of translator Sascha and reviewer Karl.</blockquote><div><br>Ahh I see. Yeah that we need to doecument at some time.<br></div></div><br>Regards Kenneth Nielsen<br>