QualityAssurance
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 proactices 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?
Upstream collaboration. How do you ensure collaboration with upstream?
Proposal of general practices
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.
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 anymore common errors or if they see that the translator is apply all the guidelines, 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. We also have 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 translators 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.
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:
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.)
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.