Translation Documentation

Translations
1

To make the lives of our translators easier, I’d like us to review the current state of our documentation and work flows, and see if there is room for improvement.

To start, what would people think of splitting the more stable “how to” translation information into a Gitbook, while keeping the more dynamic information on the wiki (e.g., translation coordinator contacts, links, etc.)?

2

Hi Kevin, is there an in-progress userguide or public example of a gitbook available now? If so, we could move the current translation stuff there, and have folks start updating it.

J

3

I’ve created the stub of a new gitbook here: https://www.gitbook.com/book/pkp/translating/details

We’ll need to determine what should stay on the wiki (e.g., anything that needs updating, like Translator Coordinator contacts) and what should move to the gitbook.

4

My two cents… (may be 3) :smile:

We need to realize that have two kind of translators in our community… experts and amateurs.
Both are doing a great job and are very important, but I mean, in some languages we have stable group of people (or a free rider) that is/are professional translators, or linguists, or… that can do an excellent work with very few indications and in other cases a little bit more guide is required.

We also need to face that sometimes we have translations that go from one hand to other and the new translator don’t follow the same grammatical rules, or style, or is not as expert… or whatever.

I think we need to clarify our expectations: We are looking for “complete” translations (in other words, “no chains left”) or we are also worried about the quality? Do we need a pro translation (with coherence, QA, testing…) or we will be happy with something that could work?

BUT (as Marco pointed somewhere) how could we evaluate the work done if we are not experts or even natives in the destination OxS lang?

Our group have been translating OxS tools (OJS and right now OMP) to ca_ES and es_ES during the last 4 years and we learn a few things that may be could be useful for others.

BTW, recently we published a paper about the whole process (that unfortunately is just in Spanish) but if you like we can translate it to English:

http://ddd.uab.cat/pub/posters/2015/132105/CRECS_a2015.pdf

First, what I like most from the process we are doing here is the “synergism” between different organizations of our university (Publications service & Master of “tradumatica”).

Publications service is introduced to the master’s students as “the client” (we show the tools, we resolve terminology doubts…) and we also help them with the tools (we install them for testing in context, we offer web forms to report errors) and in the other hand, the students offer their expert knowledge and the translation work, following the rules we define.

Both parts are happy: Publications service (and PKP community) got two pro translation every year (catalan and spanish), and the master and the students got a “real context” to learn and practice about CAT tools.

I really believe this model could be exported for other universities. What do you think?

We divide the process in 6 different phases:

  • Preparation: OxS XMLs are delivered. Glossary, translation “style
    guide” and rules defined. Translation memory (TMX) is created.
  • Translation & Correction: With omegaT help it could be done quite fast.
  • Quality Assurance (QA)
  • Testing: XMLs are returned to us and we install new testing OxS so translators could see the work done in context. Errors are captured (screen-shoots) and submitted to webforms.
  • Postproduction: Errors are fixed in the final relase and in the translation memory.
  • Deliver to PKP: Final translation is compiled and committed to github. Wiki page will be updated.

What we have learn during those years?

  • When you have multiple hands on a translation, a “style guide” is essential: Translators need to use the right verbs forms, how gender will be applied, how to deal with plurals… Translation rules need to be fixed to guaranty the quality of the translation.
  • A glossary of main terms is also very important: Main terms need to be defined and fixed from the very beginning. This is basic for the consistency of the translation.
  • When you face a complete OxS translation, CAT tools are required. This year we play with omegaT and google code SVN. Next year I will encourage to do the same with GIT.
  • During the translation period, translators and tool experts need to be in touch and answer fast to the translators doubts.
  • …

What we need to improve?

  • Sometimes our one-year-workflow don’t fit with PKPs delivers and we don’t have any language expert to commit “the few chains” that new versions introduced… Right now this is done by me, in a very irregular and amateur way.
  • We only translate a single tool each year… and two langs. And (for didactic reasons) only we make FULL translations (although lot of work could be “recycled” from former years, but we want the students to face the whole process). If we find a good way to “recycle” the work done… we could probably deliver more tools and langs.
  • Translation memories, glossary, etc are “internal” and they need to be published ASAP to the wiki, just in case others like to adapt the translation (for instance, with a different gender approach, a more informal style or whatever…).
  • In the Publication service we need to empower ourselves in the use of omegaT and the rest of the translation tools, so we can understand better our translators’ problems.
  • …

I think I never explained all this to the community and I feel this could be valuable to others. Sorry for the long post. :smile: