Query sheet

Ask questions!

TL;DR

1. Translators should ask questions (and developers should answer them).
2. Do not use e-mail to deliver your queries.
3. Develop a balanced simple/informative query system.
4. Use online query tool.

One of the most common misconceptions from the point of view of a translator is the issue of asking clients to clarify terminology/meaning of strings. Quite often translators think that asking questions is not welcomed and sends the message that “if I ask questions I am a poor language service provider”. The truth is however quite the opposite: questions should be asked as they are one of the foundations of final quality. All experienced clients encourage (and should encourage) translators to always ask for clarification, if they are unsure of the source texts.

It is the client (in our case game developer) who knows the product the most. He developed it and is the most dependable party to describe features and clarify meanings. Translators are EXPECTED to ask questions and not DISCOURAGED. The most horrendous approach presented by translators is to make up meanings, when not sure of the source text. If a given term/phrase/string is not clear and websearch does not provide unambiguous answer, the translator should ALWAYS ask the client for help.

How to exchange queries/answers?

However, asking questions one at a time and via e-mail is a disruptive strategy for both parties – asker and askee. Questions

– should be delivered in batches and answered in the similar way
– through a system that is fixed
– and allows constant access to all already delivered/answered/unanswered queries
– as well as displays queries in a way that enables to recognize their status in a flash (answered/unanswered/etc.).

This way the questions do not get doubled, the answers can be updated/amended, and both parties have a clear view on the process.

What tool to use?

Not a perfect but still a very good tool to exchange questions and answers is Excel(-ish) software. To make the query-answer process smooth, a well designed query sheet is a must. A poorly designed one makes the cooperation troublesome and in not so rare occasions it discourages the translator from asking.

The most common error while developing a query sheet is making it a huge “system” with dozens of options to choose from and fields to fill in. Rule of thumb is: inserting a single query should not take more than several seconds. If it takes longer, translators tend to ask about only the most problematic phrases/strings. In such case they are more prone to speculate the answers by themselves, which results in far more errors in the final translation.

Below is a template of a simple spreadsheet containing only 8 columns. It is intended for scenarios when only 1 translator delivering queries only for 1 language communicates with the developer. It is a good base for developing custom sheets, adapted to developers’ specific needs or texts they will have translated.

Column 1 – Number
Column 2 – Date
Column 3 – Unique string name
Column 4 – Source text
Column 5 – Proposed target text
Column 6 – Translator’s question
Column 7 – Developer’s answer
Column 8 – Final remarks (if applicable)

Columns 1-6 are filled in by the translator when doubts about the source text occur. Columns 7-8 are filled by the developer. Column number 8 can sometimes become a discussion about the choice of terms/phrases. With each query asked and answered the sheet is populated.

Go online

The huge advantage of using an online system is that

– both parties have instant access to the most up-to-date version of the sheet
– and can check, if a new question has been asked or answer to a pending query was received.
– Moreover it does not create multiple file versions that can be mixed up. It is not that hard not to notice difference between My_Gaming_Questions_to_Acme_20150328.xlsx and My_Gaming_Questions_to_Acme_20150320.xlsx. This problem does not occur when translator and developer work with 1 online sheet that is not e-mailed between them. Ockham was right: Entities must not be multiplied beyond necessity.
– I dread to think what would happen, if any offline query system be used in a scenario of 3 translator per language when localizing the game to 6 languages…

Example of a custom query sheet

Above is a fragment of one of query sheets I used. Apart from standard columns, I decided to use some additional columns:

– a three-item FINAL drop-down list.

It indicates the status of the query. Was it answered? Was the answer satisfactory for me? It contains 3 states:

– Open – a question has been only asked,
– Closed – developer provided an answer that allows me to solve the issue,
– Returned – developer’s answer was not clear, and I asked for more data,

– a crossed-out IMPLEMENTED column.

Just for my implementation-management purposes. Developer can answer dozens of questions in a batch and some answers are just confirmations of my proposed versions. If this is the case I mark given queries as IMPLEMENTED and I know I do not have to bother with them anymore. Other answers may indicate I was completely wrong with my guesswork. Then developer’s answer can be elaborate and I need to make a lot of changes in translation. It usually occurs when I proposed a wrong translation of a term that occurs very often in the game. In such cases I leave implementing the changes till later on.