White Paper: Planning Your Translation Project: Crafting the perfect RFPs or RFIs to put translation providers on a level playing field (cont.)
How Translation Happens
Behind every polished document, landing page, software application, user interface, help system or Flash presentation is a series of source files that store the content being displayed in its most basic form. In the case of most websites and software, and in many cases for documentation, these source files are not always visible to the end user. However, these base files are exactly what your provider will require in order to scope, or determine, the translation effort involved. Typically, this process is divided into scoping the number of files to be stripped down and analyzed, the number of words to be translated, and the number of hours needed to rebuild the translated files and ensure they behave like the English. The more detail you can provide on the source files you have, the more accurate your potential translation provider’s quote will be.
That said, at the RFP/RFI stage, you may not be interested in a completely accurate quote. At the very minimum, a rough quote can usually be provided with an idea of the wordcount and the file formats involved. Your translation provider will ask some basic questions and supply a list of assumptions to help provide missing but necessary details. This quote and the assumptions will be subject to change once source files are available.
Unique language challenges
Your choice of language will have an effect on the translation effort involved. Certain languages, such as German, Spanish and Russian, will result in a net increase in content compared to the English version. Conversely, Asian languages (Chinese, Japanese, Korean, etc.) will shrink in translation, leaving more space available on the page or screen. In addition, the above-mentioned Asian languages require two bytes per character rather than the standard one byte, which can result in your translated software weighing in at least twice the size of its English counterpart. Arabic and Hebrew present unique challenges as they are bi-directional, meaning the text reads right-to-left while numbers read left-to-right. Not only does this mean additional effort in desktop publishing, but the publishing software or browser you will use to display the text must support bi-directional languages and will need to be configured to properly display the translated content. These are very common occurrences which your provider will anticipate once languages and file formats are known.
If you use a content management system (CMS), you will want to ensure that it can recognize and effectively parse non-English characters, and different number, date and time formats. Again, this is a common issue, and your agency may be able to work with you to identify and prepare for these or similar issues before translation begins.
Because translated content can look and behave much differently than the English, your translation provider may recommend that they view the translated content in its final format, often offering an in-depth quality assurance pass on the version your users will see. This will help capture and address any corruptions that may have taken place after your translated files were delivered to you for further processing.
< Previous | 1 | 2 | 3 | 4 | 5 | Next >
