Bilingva Translation and Interpreting


I used their services already twice and I do agree with all said above. It's all true. I absolutely recommend Bilingva.

Vikotriia K
Oakland, CA

[ read more ]

Planning for translation

The first step towards website translation and localization begins long before the first page of the new website goes up. Decisions about possible translation and localization need to be made during the planning stage, since they can influence your choice of platform and language to create your future website. All pros and cons of a CMS system vs. plain HTML pages, custom scripts vs. static pages need to be considered roughly during the same time as the wireframes are created.

From the localization standpoint, CMS systems offer the most versatility and ease of use both for you, the client, as well as for us - your translation provider. All website text is neatly packaged in so called resource files, which can be easily exchanged, changes can be made without accessing the website itself, quickly uploaded back to the website and go live within minutes of you receiving the translation. However, CMS systems are complex to maintain and deploy. If your website consists of just a few static pages, it would be a lot easier to keep several copies of these pages, each holding text in a specific language, and serve them to the user using some kind of a switch method.

Localizing static HTML

We'll discuss the aspects of localizing static HTML pages first, and address server-side scripts and CMS systems in later blog entries. Let's say, you have a fairly small website, which you need to translate in just a few languages. For example, your content will be served in English and Spanish. The easiest thing to do would be to maintain several directories on the server, named using standard localization convention. For example:

{codecitation style="brush: xml;"} your_domain_name/ index.html about.html es/ index.html about.html {/codecitation}

Your English-language files will be placed in the root directory for the particular domain, while any additional languages will be contained in separate directories. Keep the links between the pages related, so that when you switch to another language, all the links will point to the files within the same directory. Not only you save yourself the headache of maintaing double the number of links you normally have, you can easily deploy additional languages as needed.

Now you need to have the contents translated. This is where we come in. If you thought about the possibility of translation before you laid out your HTML, and kept the text separately from the HTML markup, you now could send us just this text. We will translate it into the languages you need and send back to you for placement into HTML templates.

Don't have the text separately? No worries! Send us HTML files, and we'll edit them directly. We have the tools (and we'll talk about them in the future blog entries) to edit text without stripping out tags, so that you get the same markup back, and translated pages ready for upload.


All done? Not quite. If you used any graphics that contains text - buttons, banners, images - chances are, you need to localize them as well. This is a little trickier: the process is mostly manual, so we need to have access to all the images; we go through the images, translate the contents, and send you back a table with columns which contain the original text and all translations, so that you could match the translation to the original, and recreate your website collateral in the graphics editor of your choice.

Final review

Quality control with localization is essential. Now that you've uploaded translated web pages and graphics on the website, our translators can review that the translated text was transferred correctly: no accent marks lost, no incorrect hyphenations present, the symbols are located where they are supposed to be. After the check is complete, your translated website is ready to go live!

See also:

  • Step 2: localizing static HTML pages