Help:Extension:Translate/Translation best practices

Things to cover Not decided whether this page should be translated or not. probably some language-specific practices (links) will be needed.
 * usual stuff about variables, links, what to translate
 * links that explain these in more detail
 * http://www.africanlocalisation.net/sites/default/files/FOSS%20l10n%20guide%20-%2020110214-en.pdf
 * start digging http://translate.sourceforge.net/wiki/guide/start
 * encourage message documentation and explain how it works in Translate
 * less important: encourage terminology (and promise we'll have awesome feature to handle it in the future, perhaps even explaining why OmegaWiki is not the way)

Becoming a good translator needs lots of practice. Many if not most volunteer translations don't have formal translator training. It is no wonder that the quality of many volunteer translated works leaves something desire. But even bad translation is almost always better than no translation at all. There is always more to translate than there is translators. For these reasons translators should group together and welcome new translators.

One can become a good translator in specific contexts even without formal training, but it needs many years of experience. It is possible to speed up this process, if we provide direct and constructive feedback through a review process. Even experienced translators can learn and it's always good to have someone else check for spelling errors and such.

But the long journey starts from the basics. Translator should know his own language, the spelling of words and what is considered as good grammar. For small languages that are just starting to use computers and Internet even the way to spell words might still be under discussion. Regardless, translator should be prepared to create something new - there are bound to be words and concepts that not been translated before into their language. And obviously translators should understand enough the language they are translating from.

Getting started
Before starting, make sure you are able to type and read in your language (Chapter 3 of FOSS l10n guide might help). This might involve installing new fonts and keymaps for your computer.

Orient yourself (Chapters 1 and 2 of FOSS l10n guide). You might find many reasons to translate, whether you just do it for fun, hone your skills and accumulate credit or just want to give something back to the causes you support. New translators find useful tips from Chapter 4 of FOSS l10n guide. You should understand and adopt the core principles of translation like translating the meaning, not word by word, but still trying to be as close as possible to the original text.

Try to join pre-existing translation communities and ask others to review your work. You will encounter non-linguistic markup like variables and wikitext when translating: Chapter 7 of FOSS l10n guide gives examples of those. The gist in that is to recognize what parts should be left untranslated and what is the special meaning of them.

Aim for quality
Whether you a translator or translation admin, the Translate extension provides you the tools to produce higher quality (and more) translations. High quality can only be reached if everyone does their part. For the social aspect we encourage translations to take ask, don't guess attitude and translation admins should be responsive to questions.

Message documentation
The plain text is not enough for making good translations. This is gets more relevant the shorter the text is, but applies to all texts. Each message has a place to provide context and more info for translators. If you consider that it might take ten minutes to write good documentation for a message, but that documentation will save each of the potentially hundreds of translators a minute and produce higher quality translation, it should definitely be worth it.

It is possible to configure Ask question button show up in the translation editor. This provide low barrier and very direct way for translators to make sure they are doing a good translation, instead of doing best guess translation. Of course you should make sure that someone will be there to answer the questions and update message documentation, or you will only discourage translators.

The message documentation is wikitext and contain anything from links to images.

Translation review
The second important aspect of quality assurance is review. The review user right, which is given by default to translation reviewers user group enables users to accept translations they haven't made themselves. Multiple people can review the same message, and the software display the number of reviewers for each message.

Users can review messages for any message group or choose the Recent translations message group to review new translations as they come on. The accept buttons are shown in the accept translations and review all translations tasks. All reviews are logged to reduce and detect misuse. Message documentation is in important role here too, because the reviewer needs to be sure that the translations not only has the correct spelling and terminology, but that it also suitable for the context.

This can combined this with message group workflow states by having 'proofreading' state which can be used to direct the work done by reviewers.

Consistency
Translation memory can help a little to keep wordings of similar messages consistent. It cannot enforce consistent use of terms in different kinds of messages. For now there is no technical solution for this problem, but you can make glossaries and link them from the group description or use in message descriptions. When multiple translators work together is crucial that they first of all recognize the terms, and secondly that they use the same translations for them. When making glossaries, it is also a good idea to write short definition of each term instead of just providing translations. The definition helps translator to understand it and come up with good translations.