Hi Sebastian, Il giorno mer, 11/06/2008 alle 10.02 +0200, Sebastian Heinlein ha scritto: > Hello Arne, Jerome, Danilo and Ubuntu translators, > > at UDS Prague I had a short discussion with Arne and other translators > about Rosetta and the general translation process. Here is a summary of > the raised issues.
Thanks for sharing with us! > 1. Policies > > As far as I know Canoncial wants to target a Wikipedia-like approach > with Rosetta: Many people provide suggestions and correct each other > with a kind of quality assurance through the translation team. This > policy could be perhaps ok for translations with very few upstream > translations, but it doesn't scale for the majority of the European > languages. If a translation team is completely open, this kind of approach, from my POV, could be more error prone. Lots of suggestions from first time contributors and translators that don't know the guide lines that a translation team could have and this could also lead to some upstream upset (that I have already heard even for a closed/moderated team). The idea behind this approach is great: translations, in term of translated strings, could get a boost, no doubt... but is possible that quality could decrease (this isn't the case if all people involved know about guide lines, upstream-downstream... but this usually happens only in a very-perfect-world). > As western Ubuntu translators we only have to translate a small subset > of packages, basically the ones written under the Ubuntu umbrella, and > the documentation. Furthermore we have to spot for import errors and > keep an eye on single missing or changed strings. What we want to avoid > is a brain split between upstream and Ubuntu translations. For this task > we only need a team of about 5 to 10 active translators, who are capable > and interested in polishing. For the Italian team, we are in 2-3 people doing this kind of work: keeping an eye on upstream (me and others are GNOME and TP contributors and manly my translation effort is with upstream, trying to minimize downstream delta) and doing some "seek-and-revert" work. > So the education of good translators is more important to us than > getting a huge number of translated strings (of questionable quality). I completely agree: it's better to have less but well translated strings than lots of not so high quality. It would be great to have a 100% translated system, but that's something that needs and takes time... lot of... > Furthermore it is also very time consuming to review and approve > suggestions. I don't see a real speedup compared to writing them on my > own. Especially since there is no way to provide feedback to the > translators in Rosetta. If there is no contact outside of Rosetta I have > to correct the same errors again and again. > > 2. Review instruments > > Although Rosetta provides some reviewing features there are still some > issues. > > At first a changed and approved suggestion gets submitted under the > approver's name and the original suggestion gets lost. This makes it > impossible for the original submitter to see what was changed. > Furthermore his or her credits get lost. I am not aware to which extend > this is a bug. Pros and cons here too. If we have to keep all suggestions, probably the interface will result in a complete chaos. I don't know what could happen if ten people make ten different suggestions (maybe only for a typo) for all the strings in a page... if i have to review those strings, yes, it will take me less time to translate them from ground up. But as you said, we loose track of the review process... > Furthermore high lightening the changes between suggestion and approval > would make them more visible. Mostly there are wrong terms, typos or > grammar issues. That would very precious, indeed, something like Pootle (I use Pootle for Compiz translations) does and it's very useful in reviewing suggestions. > Secondly it would be nice to have a kind of comment field for changed > suggestions. +1 for this too! Translators comments are very very useful (Pootle supports them). I don't know the implications that could have inserting comments inside LP-Rosetta (DB tables, code, whatever...), but that would be of great value. > Currently I have to open up a chat window or write on a > wiki page all the changes with comments to provide feedback to a new > translator. This involves a lot of copy and paste work. When I review translations from new translators (something that doesn't happen that much though, probably because people get a little scared with the high demanding skills and quality and all the documents that we want them to read...) I report them my impressions, the strings numbers that I changed and what I changed... yes, it's a time consuming task... but I think that reviewing is not that easy anyway, even with the best solution at hand. > 3. Quality assurance > > For the German team I would like to limit the persons who are allowed to > make suggestions for out of two reasons: At first I would like to force > them to get into contact us before working on the translation to help > them to improve their quality, see above. Secondly most suggestions just > get not approved since they have not been done systematically enough to > send them to upstream. Personally I won't accept translations for > non-Ubuntu projects if I don't know that the translator will cooperate > with upstream. Currently many people just start to translate and in the > end waste their time, since the output does not meet the standards. This > is a pity. And I always have a bad feeling telling the people so. > > Therefor I would support splitting the team into two parts: a translator > team who is allowed to only make suggestions and an approver or qa team. > This issue has been discussed for ages now. I remember talking with > Carlos about this on my first UDS Paris back in 2006. I don't want to > enforce this structure for all teams, but I know of some teams who would > welcome this more fine grained privilege system. Is the German team an open team? Or are you seggesting a new level of priviledges? The Italian one is "closed" and people before entering the team need to make new suggestions that need to be reviewed by someone approved in the team (all team members, if they want, could review other people translations, it's a task that all approved translators should be able to do). In this way we have a QA team for translators, once the new translator is in the team, he/she should be able to go on... I have to admit the it's a little hard right now entering the Italian team, but the quality of the translations have to be high and people involved in the translation team have to know the implications of modifying a translation that comes from upstream or other projects, and what I'm trying to push is to collaborate with upstream. > 4. Upstream collaboration > > Are there any plans to support a version control system import/export > like in the RedHat tool? I've never used nor seen that tool... can you point me somewhere? > Or to generally improve the system? What is the > status on automatically importing from upstream version control system > (GNOME, KDE)? Good question! I've always wanted to know better how the system works. > 6. Documentation > > Currently there is not sufficient documentation of Rosetta especially > introductions for new translators. In this area the translation teams > could collaborate and write a common documentation. Yes, that would be a great collaboration effort between all of us. Really, and I think it wouldn't take us a lot of time to do it; looks like we all have a common ground here for what needs to be done... > Furthermore the policies of Rosetta internals are not available in a > central place. E.g. I often get asked by upstream, team members and from > outside how "we" handle e.g. overwrites in Rosetta. Most times I can > only give them an "AFAIK" answer. Would be nice to have document to > point to. FAQs: What happens with the overwrites if upstream includes > them? Do we follow upstream again? Get translations of the current > stable branch (hardy) automatically applied to the same string in the > development version (intrepid)? Another good question is "How often are there updated langpacks?" I know it's something monthly... but many people ask this and I'm not always sure... > > 7. Best practice > > It would be nice to see a kind of best practice discussion among the > translation teams. How do you handle qa? Think I already answered this question, but if you need further information... let me know. > What are the formal > requirements to join your team? Does it make sense to raise the barrier > for you (in a non technical way)? When someone approach us and want to join the team we ask, basically: - good knowledge of English - good knowledge of Italian (sounds wired, but it isn't at all...) - to know what you're about to do These imply: - signing the CoC - following the rules of the community - reading guide lines form GNOME TP and the Italian TP - setup a wiki page with contacts and whatever - letting other team members review translations made > Do you have got translators with clear > responsibilities (e.g. a special set of packages)? Not at all... we ask if someone want to take up a translation task, but that's not mandatory to have only one person involved. > How do you manage the > contact with upstream: the large projects e.g. GNOME and KDE and the > smaller ones? For example the German KDE translators have got a member > in our team, who does a great job. I'm a GONME and TP translator, and in the Italian Ubuntu team there are others GNOME translators, so we always have a link with upstream. We are missing some KDE upstream contributors and Xfce too... > Or just to share tricks and tips e.g. > manipulating the batch attribute of the URL [3] to get a better overview > or adding custom search engines for Rosetta to your browser. :) Yeah, they have now limited that... I've been using also 1440 batch for the complete list of packages! :) It's easier like that to go directly to a package... but even with 300 it's not that bad. Would be useful to have a simple page with all the links (without statistics, translators name...). Bye! -- Milo Casagrande <[EMAIL PROTECTED]>
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
-- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
