Translation Quality

At the beginning of the project, the localization manager and translators will familiarize themselves with your product. This process involves the following:

• We ask for a software build to install on our machine, or request access to the online version.
• We will ask you to fill out a Style Guide to find out, for example, details such as: is there a limit on string length; is there a principle governing how string keys are named; are there any strings and words that should not be translated, and how should the user be addressed, formally or informally?
• We determine whether you have a glossary, which is a list of terms with definitions, such as character names and the names of items in the game. If you don't have a glossary, we will help you draft a list of terms using special translation quality assurance tools and then decide which of the terms should be included.
• We will ask you to take screenshots of the software, if possible. Based on the screenshots, translators match the translated string with the real screen in which it is used.
• We create a project on an online platform and load the strings, screenshots, and glossary. Then we will invite translators to the project. We will ask them to familiarize themselves with the materials and try the software. We control project performance using a checklist.

The project manager will decide whether a user manual, glossary and screenshots are needed on a project basis.

The translators will start working once the project is prepared. Translation is carried out on the online platform. We use several platforms, but the set of quality management tools is similar for each one of them:

• The glossary highlights terms if they occur in a string.
• Screenshots are displayed next to the relevant strings to be translated. In this way, the translator can see the context.
• The translation memory tells the translator if he has previously translated the same text. This ensures a consistent translation.
• Automatic quality control (QA Check) warns of errors, such as a typo or a missing punctuation mark at the end of a sentence.
• Comments give project participants the opportunity to ask the client a question directly and specify, for example, the context or values for the variable.

Together these five tools help to ensure an accurate translation.

The above-mentioned tools will help translators ensure that there are no mistakes. The "No issues" rule is a standard part of the terms of reference that translators receive. However, after the localization is completed, the manager will also monitor the translation quality and check whether this rule has been observed. The manager will review the results of the automatic quality checks and if there are any errors, will ask the translator to check any problematic strings again.

The translator will also approve the translation of each string. Proofreading mode on the online platforms is used for this. The translator will activate this mode and then proofread each line. If there are no errors in the string, then they will approve the string. If an error is found, then the translator will fix it before approving the translation. This rule is also a standard instruction that forms part of every translator assignment.

Together these two rules are called self-certification or self-checking.

In addition to translation and self-checking, you can also order proofreading to be performed by a second translator who will act as an editor. They will familiarize themselves with the product and proofread each line while following the "No issues" and "100% approved translations" rules described above.

Of course, you do not have to include editing as part of the project if you want the best price for localization. The table below will help you understand the difference between a simple translation and a translation with proofreading.

After translation, verification and proofreading, we recommend testing the localization in the product itself. You can choose from two options:

• Translators will run your software and perform all actions to launch each available window with localized content. Thus, the translator will check all strings to ensure they match the source text's meaning and fit within parameters of the fields and buttons. For this the translator needs step-by-step instructions: for example, user histories or test cases. If there are no test cases, we can prepare these ourselves.
• We will ask you to take screenshots of all the windows in all languages. The translators will examine the screenshots and check the translation. Developers choose this option about half the time. To do this, they automatically take a screenshot of each screen using special tools.

Translators enter each bug into a bug tracker or Google spreadsheet. Each entry indicates the problem string, describes the error itself, and proposes a corrected version.

The cost of testing is calculated based on the number of hours spent on checking.

Rates are shown in US $ per hour of work by a professional linguistic quality assurance tester

If there is an inaccuracy in the translation, we will correct the translation at our expense, analyze why the error occurred, and take measures to avoid repeating such errors in the future.

We use this seven-step process both for the first turnkey localization as well as for all subsequent updates.