Ubuntu Wiki

Introduction

This document presents a collection of the different approaches to quality assurance in translations followed by different Ubuntu translation teams.

The purpose is to share those practices with all other translation teams and to eventually provide a list of best practices and evaluate the idea of drafting a general policy to ensure the quality of Ubuntu translations.

If you want to share your team's practices, here's a suggestion for some of the questions you could answer:

• Membership policy. Are you a Moderated or Open team?

• Membership application. If you are a moderated team, what is the process to become a member?

• Translation quality. How do you ensure the quality of translations? What's your review process?

• Colaboration with other translators. How do you communicate with other reviewers or translators (for feedback, annoucement, common errors).

• Upstream collaboration. How do you ensure collaboration with upstream?

• Feature request. Name one (only one) feature that your team would like it to be implemented in Launchpad. Please describe the problem (most important) and how do you expect it to be solved.

• Additional information. Anything else you'd like to add.

Proposal of general best practices

Team membership

Starting a new team

Existing team

Adding new members to the team

Ensuring translation quality

Upstream collaboration

What do teams do

Arabic team

We have a moderated team, with only few members, and who is willing to contribute do so by suggesting translations and another team member will review and accept it.

Catalan team

We are a moderated team. The main aspects of our policies are:

• Communication: we make clear to all contributors that communication is very important, and we ask all of them to join our mailing list.

• Guidelines: we have a canonical (as in the adjective, not the company ) set of guidelines and glossary used for Ubuntu and nearly all other free (sometimes even also commercial) software translated in Catalan. I believe that's one of our strongest points.

• QA: all translations must be reviewed before being approved. We use the mailing list for reviews, and the translation group members can also approve suggestions in Launchpad.

• Workflow: we normally assign translations to people (or they pick them up), and we track their status in the wiki (as an overview of what's been discussed in the mailing list) -> https://wiki.ubuntu.com/UbuntuCatalanTranslators/Llistat

• Membership: we only accept members who've done a sustained contribution, follow our review process and guidelines and have proven to provide translations up to the standards. That said, we also make clear that you don't have to be a member to translate Ubuntu into Catalan. Anyone who submits a translation (either via PO file on the mailing list or through suggestions in ) and asks us for review will see his/her translation in Ubuntu.

• Upstream: we ensure active collaboration with upstream by participating in the upstream teams. In fact, the usual path has been so far joining the upstream teams and then coming to Ubuntu. We've got people from Debian, GNOME and KDE. For those upstreams in which we do not actively contribute (Mozilla, OpenOffice.org), we've got a fluid communication with their members.

Danish team

Danish translations are performed by dansk-gruppen, a group of loosely organized translators of free software (around 10 active people). Individual projects (Ubuntu/Launchpad, GNOME, KDE, ...) have different coordinators who are active in dansk-gruppen. Almost all communication is done via the group's mailing list.

Below are two sections. The first pertains to the general workflow for dansk-gruppen (which we would like to be able to apply for Ubuntu as well) while the other pertains to Ubuntu (and often Launchpad in general).

• Membership: you are a member of dansk-gruppen to the extent that you participate on the mailing list (implicitly, the only requirement is therefore the willingness to communicate). This means you can translate and proofread, but usually not commit translations.

• Translation quality: if possible, we work on po-files. A translated po-file (or usually a specially formatted 'podiff'-file) is sent to the mailing list for proofreading. At least one person proofreads it and sends corrections per email. The translator incorporates the corrections and sends the corrected po-file by email to be committed by the project coordinator.

• Collaboration with other translators: The entire workflow is implemented on the mailing list as mentioned. We have an IRC channel which is mostly used to introduce new translators, and a wiki which is used to maintain a list of po-files or modules that are currently being translated so they don't get lost in the email traffic (requires a bit of work to keep it updated though, mostly if the po-files are very small). We have a webpage with a list of standard conventions for translations.

• Upstream collaboration: N/A, we are upstream.

• Feature request: (see the next section)

• Additional information: Getting new translators is difficult because of the learning curve, but experienced translators have a very high throughput.

Launchpad/Ubuntu

• Membership policy: Many of the experienced translators are members of the ubuntu-translators group for practical reasons. We would like to have only 1-2 administrators who can approve translations in large chunks at a time (like committing one or more po-files at the same time), aside from a larger group of translators who can translate, proofread and correct strings before asking the administrator to commit.

• Membership application: People requesting membership are directed to dansk-gruppens mailing list. There is no systematic procedure to accept new members, we'll discuss it on the list when it comes up.

• Translation quality: During "peacetime" we prefer to download and upload po-files from Launchpad and use dansk-gruppens procedure (above) for the workflow. Other than that we look through suggestions on Rosetta and approve them, or correct-and-approve them. We have no efficient means of communicating with the translators though. We do not translate and approve strings in one go, preferring to have one other translator proofread. Communication is tricky because Rosetta has no 'comment on this string' feature, and pasting strings into email or IRC programmes is time consuming.

• Collaboration with other translators: If they join the mailing list all is well. If they don't, there's no communication at all. They keep writing suggestions and we keep rejecting them for the same errors.

• Upstream collaboration: Since we are the same people translating upstream, everyone is more than willing to coordinate. But the Launchpad import delays make it impossible to know which translations are up-to-date, and the time it takes to manually download both upstream and downstream po-files, merge them and then upload, makes this highly inefficient. Furthermore it is impossible to see which English strings were added by Ubuntu, and therefore we do not know which parts we should translate, and which were already translated upstream. The result is that Ubuntu-specific translation work is done just before a release when we absolutely have to. Even then some modules appear to not be properly synchronized with upstream, and we don't know the schedule for such synchronizations.

• Feature request: It must be made completely clear which English strings/modules are specific to Ubuntu, and which strings originate elsewhere. This means that each module must include an indication (such as a link) to its upstream message source, and this indication should be clearly visible in Rosetta (or a statement saying that this is upstream, as defined by whoever set up that project or source package). Ubuntu-specific additions to upstream templates must be separate templates.

Galician team

• Membership policy: Galician team is moderated.

• Membership application: to become an approved member it is necessary to follow each of the steps outlined:

  1. Be subscribed to the ubuntu-l10n-gl mailing list.
  2. Do translation suggestions (at least 100 strings) to be evaluated. If the translations are OK (grammatically correct and following our wiki guidelines) the candidate becomes an active member.
  3. We ask the new members to check if someone has already started the translation of the package (in Launchpad or in upstream).

• Translation quality: we do not have a strict QA policy. When someone detects an incorrect or inconsistent translation, the problem is discussed in the mailing list.

• Upstream collaboration: we maintain a close contact with the upstream teams, specially with Proxecto Trasno (which includes several Galician translation groups: GNOME, KDE, Xfce, LXDE, Debian...) and with Mancomun (Galician Government's Free Software Initiative, responsible of the translation of OpenOffice, Mozilla...).

Indonesian team

We are a moderated team and use a similar ruleset as the Spanish and Swedish teams, with some distinct rules:

• At least 500 karma (translation) to be a member Ubuntu-id translator
• We just give 1 year for membership
• Our member must be subscribed to the ubuntu-id mailing list, so we can contact him/her directly

Italian team

• Membership policy: team is moderated

• Membership application: to become a member, a person needs first of all to subscribe to our mailing list (we also have an email alias that points to the mailing list, but that's only for short communications and for bugs) and sign the Code of Conduct. We have a wiki page where we list all the packages that are translatable by the Ubuntu Translators team, plus other packages that are not under the Ubuntu umbrella but that is possible to translate and don't have an upstream translation. A wannabe translator chooses one of the free packages so we ensure that only one translator at a time is working on it. They leave suggestions, and an approved translator reviews their work, suggesting corrections, reporting errors and so on. It's the translator duty to apply the corrections in order to learn their errors. There is no fixed time or a fixed karma-level to become an actual translator: if the reviewers don't find any more common errors or if they see that the translator is applying the guidelines in the best way, that's fine. It's also important that they understand the work flow: you get assigned to one translation, and don't wander around Launchpad translating whatever comes to your screen. You can do other translations inside Launchpad as well, but we really encourage translators to let someone review their work and to let us know what they are translating. We have also strict guidelines that are the same as upstream, they are linked in our wiki pages, and reading them is a step in the process to become a translator.

• Translation quality: all translations have to be reviewed and all translators in the team can do that (that they do it, it's another story). The review is done through the mailing list: the reviewer looks at the translations in Launchpad and reports the problems/errors on the mailing list. It's the translator duty to correct and apply the suggestions and to discuss them. It's a *really* hard work, but this ensure the best quality for us at this time.

• Upstream collaboration: if we can do a translation in Launchpad (usually for the release) and we know that there's no translation upstream, first of all we contact upstream (whatever/wherever that is) asking if it's OK for us to do it. If we have the OK, we do the translation in Launchpad, review it, and then send it upstream. Sometimes we also do a review upstream before sending it. Some of our members are also upstream translators (GNOME, Debian, KDE, OpenOffice).

Japanese team

We(japanese translators) totally agree with this too, we have same face a challenge.

Japanese translators destination are

• - get more quality of translatirons. - keep open policy.

In our discussion, we access to two bottom line, currently, we had remain inconclusive some reasons.

• Plan A) mandetary policy:
  • set as moderation team, but it is not open.

  Plan discretionary policy:

  • define and broadcast "use fuzzy" rule, that provide open aproach and minimum retention of quality. But this aproach based on "awareness", that provide limited quality.

Plan A/B is good for neither one thing nor the other.

Now, we plan to go with Plan A, but LP has no function for translation reviewing, team moderation is good for work, but member invitation and catch up/mentoring are not. So, if translation coordinator want to help another translators, he/she must work harder. It is not good way, we need more discuss about team aproach in Japanase translations.

So, we proceed plan now, as experiment. This is temporary way, we benchmark discretionary policy.

Portuguese team

• Membership policy: team is and has always been moderated.

• Membership application: to be approved as a member you have to:

  1. Be subscribed to the mailing list.
  2. Do translation suggestions for a period of time. If the quality of the submissions is considered acceptable (grammatically correct and following our guidelines) the candidate becomes a member of our team. We are also considering introducing a mentoring program for new members.
  3. Team membership is time limited and its renewal is (mainly) dependent on the quality of past contributions.

• Translation quality: QA is ensured by strictly following our guidelines. We try to flag for review any contribution that is not on par with our quality standards. We try to respond as quickly as possible to any bug opened for our language packs. Finally, we are in the process of discussing on how to further improve our team's QA.

• Upstream collaboration: We try to maintain a close relationship with upstream projects. Whenever possible, we encourage our members to participate in the upstream teams.

Romanian team

Membership of Romanian Ubuntu Translation team is somehow a certification that a person can submit translation of good quality for Romanian.

This is why we give 1 year membership and users can update their membership. If they are active, they will update it... otherwise will be listed as inactive.

Signing the Code of Conduct is a great thing and we tried to make it requirement but it did not work, because many translators were not able to use GPG and sign it. Basically in Ubuntu Translation Team we have many person willing to help free software with translations but they are not technical users and they found it hard to work with upstream projects.

With the new feature of LP to contact even persons with hidden email, we do not require them to join the mailing list (it's only a recommendation). If there are problems I contact them.

Before accepting new members to the team, we ask them to use the localization section from our forum and post there links to their work. We will review the work and give feedback as an answer to their post. We found out that our translators prefer forums over mailing list.

Russian team

We're moderated team. Person who want to join group need to have at least 100 points owing to translation in Rosetta as freelancer. User must to subscribe at our maillist. All major instructions and 'howto' available at our wiki page and forum. Also we have IRC channel, but atm it is not very populated.

Slovenian team

The team has become moderated in answer to some complaints regarding the quality of the translations.

• Communication: a mailing list for the members

• Quality: a generic bug is opened against language-pack-sl to serve as an example how to fill a bug related to the translation. Ubuntu Slovenian Translators team is subscribed to this package.

Spanish team

Our team is a moderated one. To become a member, you need to:

• Sign the Ubuntu Code of Conduct.
• Do translation suggestions for, at least, one month before apply to the team.
• Be approved by, at least, two members of team, in order to ensure the quality of the translation work.
• Use a "neutral" Spanish (not localized in any Spanish-spoken country).
• Subscribe to the team mailing list and request to be a member.

All the above requirements are collected in the wiki:

• https://wiki.ubuntu.com//UbuntuSpanishTranslators

Swedish team

The Swedish Translator Team) uses a similar ruleset as the Spanish team. Everyone can submit suggestions but only 2-4 persons are members of the team and have the possibility to approve suggestions.

We recommend that all translations take place upstreams and then imported. My calculations shows that 95% of all Swedish translations are imported from upstream into Ubuntu, the rest is done in Launchpad (ubuntu-docs etc.)

Tamil Team

• We are a moderated team. Any one can join the Team. Upon applying the membership is approved for a period of one year. People who are active will generally renew the membership & subsequently approved. On ensuring Translation Quality, we are about to come up with a better process.

  We directly contribute to GNOME & KDE upstream.

CategoryTranslations