Many words can be translated in different ways and it’s important that everything we translate come out the same.

The solution is a glossary.

A glossary helps produce consistent translations, as it shows how phrases were translated before.

Clients can create entries for important phrases. These entries can include the translation and serve as guidelines for the translators, or remain untranslated, so that translators can suggest the right translation.

As translators work, they too can add glossary entries. These entries will help translate the rest of the project consistently and also serve as reference for other translators who work on the project.

Creating a glossary

Each client now has a new Glossary tab. There they can manage their own glossary.

Glossary terms can be added and edited individually, through the web interface and also be managed offline using a spreadsheet.

Glossary management page

Using a glossary when translating

When translators work, they will see glossary entries highlighted in the text. This clip shows how translators use the glossary when translating Software localization project.

What’s next

The glossary functionality is very new and still in Beta. It’s working for Software localization and for Instant translation projects.

Coming up next:

• Full support for glossary when using Translation Assistant. This will include all kinds of website translations as well as Help & Manual projects.
• Export and import to industry standard tools (Trados).
• Loose expression match (plurals and other variations).

Let’s get started using the Glossary to create better translations. Let us know how it’s working for you and we’ll do our best to perfect it.

<script type='text/javascript' src='swfobject.js'></script>
 
<div id='mediaspace'>This text will be replaced</div>
 
<script type='text/javascript'>
  var so = new SWFObject('player.swf','mpl','600','416','9');
  so.addParam('allowfullscreen','true');
  so.addParam('allowscriptaccess','always');
  so.addParam('wmode','opaque');
  so.addVariable('file','mp4:using_glossaries');
  so.addVariable('streamer','rtmp://sxnz2qsq127rj.cloudfront.net/cfx/st');
  so.write('mediaspace');
</script>

What’s new:

1. Translating iTunes description together with the iPhone app resource file.
2. Built-in QA checks for Text Resource projects.
3. Preventing product names from being translated.
4. Automated report for too long and short translations.
5. Using a single Text Resource project instead of many Instant Translation jobs.

Including iTunes description with resource file translation

We’ve made it extra simple to manually add the iTunes description to the Text Resource project, so that they can be translated together.

To add the iTunes description to Text Resource projects, go to the Text Resource project.

1. Click on Manually add a string to the project.
2. Enter any label you like (for example, iTunes description), enter the iTunes description in the text to translate and a comment for the translator.

Now, iTunes description is part of the project and will be translated by the same translators working on the application.

To pick up the translation, click on View or edit translation. The text you’ve added manually and its translations, will be on the last page of the strings-list.

Even though you added a new string to the project, it’s not going to be added by mistake to the application’s resource file.

QA checks for Text Resource projects

When you translate strings that appear in an application, the translations must include the same formatting information as the originals. Otherwise, the application will fail when running with the translation.

For example, supposing we have this string:

Visit our <a href="%s">online manual</a> for more info!

The Spanish translation should be something like:

¡Visite nuestro <a href="%s">manual en línea</a> para más información!

But, if the translator drops one of the HTML tags or doesn’t include the %s argument, it’s not just going to display bad, it’s going to not work.

Text Resource projects now automatically check against formatting errors. A new checker makes sure that all formatting strings that appear in the original also appear in the translation.

When the translator saves the translation, the system will validate the formatting markers and make sure that they match. Otherwise, translation can be saved, but cannot be marked as complete.

If formatting strings in the translation don’t match those in the original text, the translator will see this warning:

Translation with formatting strings mismatch

But wait, there’s more!

Protecting product names from being translated

Supposing you sent an application called Shrink Pic for translation. Shrink Pic is the name of the program, so we don’t want it translated.

You can instruct the translator not to translate these names. But now you can also make sure they’re not translated by telling the system that these strings are required.

1) Click on the Edit description link in the project description box.

2) Edit the description and include the strings that need to be preserved.

In this example, I’ve added both “Shrink Pic” and “OnTheGoSystems” to the list of required strings. Now, the system will make sure that if any of these strings appear in the original, they will also appear in the translation.

String length report

English texts are normally shorter than German, Spanish, French (and other European languages) and longer than translations to Asian languages.

String sizes are hard-coded in many applications, so if translations are too long or too short, the application doesn’t display correctly. If you’ve got just a few strings all displayed on a single page, it’s pretty easy to spot that, but what if your application has hundreds of strings and dozens of pages?

The Text Resource projects can now produce a report showing the length of translations, compared to the original text. You’ll see immediately which strings require checking and can either ask the translator to change them or change the screen area in the application.

To access this, click on View or edit translations.

Then, at the top of the page, click on String sizes report.

You’ll get a table showing the breakdown of strings in the project, ordered by the length of the translation (relative to the originals).

Each row shows how many strings exist in each language for the size ratio. For example, in this project, there are 4 Spanish strings that are 60% the size of the original English and 64 Spanish strings 140% the size of the English.

Rows with size ratio between 70% and 130% are marked in white and are usually OK. Strings shorter than 70% or longer than 130% might cause display issues and should be reviewed.

Click on the left-hand column indicating the ratio to see all the strings with that size ratio.

Try using Text Resource project instead of many Instant Translation jobs

If you’re using our Instant Translation projects for many texts, you should consider using the Text Resource projects instead.

This will allow you to:

• Manage just one project, with all the texts translated to all languages.
• Choose your translators (once).
• Communicate with the translators to explain what you need.
• Make sure that the same translator always translates for you.

In the past, it was a bit complicated to use Text Resource projects for managing short text translations, but no longer.

Here is what you should do:

1. Click on Projects->Text resources.
2. Create a new Text Resource project.
3. Provide a short description of what your texts are about (you can always edit that later).
4. Click on Manually add a string to the project. You can repeat that many times to add all the texts that you need.
5. Select the languages to translate to.
6. Choose your translators.
7. Start the translation.

True, there are more steps involved than when creating Instant Translation jobs, but you only need to go through that once. Next time you have new texts to translate, return to the same project and click again on Manually add a string to the project.

All short texts will be organized in a single project. You can enter required text just once for the entire project without having to do it over and over again per text.

But more important than saving a few minutes, is the fact that your translations will improve drastically. Since all texts go to the same translator, you’ll get much more consistent translation. The translator also has an open chat session with you, so it’s easier to explain what the text is for and answer any questions.

What do you think?

We’ve done our best to improve the system and make it easier for you to get your job done.

All these changes were done due to great suggestions we got. We’d love to hear your feedback and see what you think.

This glossary will tell how to translate special terms to different languages and will be used for all the client’s projects.

Let’s start with an example.

iPhone golf-instructor application

Supposing a client is creating an iPhone application that teaches how to play golf. That client will have a multilingual website, an iPhone application, customer support translation and some small texts to translate from time to time.

It would be nice (for us) if we could get everything to translate at once, fully documented and explained. In practice, it doesn’t work this way.

First, we’ll get the iPhone application’s texts with minimal documentation. The translator will ask questions and get to know the application.

Then, a few weeks after, the website will follow and then customer support calls will trickle in.

It means that several translators will need to work on the same project. One on the iPhone application, another on the website and whoever is free first on small translations that follow.

In order to produce consistent translation, the translators will need to have a glossary that tells how to translate phrases used repeatedly. Each client would have a glossary, used for all projects and accessible by any translator working on that client’s projects.

How the shared glossary would work

Both the client and translators would be able to add phrases to the glossary. Clients can create the glossary entries and translators can add both the entries and their translation.

For instance, the Spanish translator would probably add phrases like ‘trainer’, ‘club’ and ’swing’. Then, when the client starts translating the website to Spanish and the word ‘trainer’ appears, the (possibly other) Spanish translator would already see that it should be translated as instructor.

Later, when the client also decides to go French, the French translator would see that ‘trainer’, ‘club’ and ’swing’ require special attention and would first add their translations to the glossary.

Glossary everywhere

Glossary entries would be used for any kind of project done by ICanLocalize. No matter what we’re translating, if the text includes a phrase that appears in the glossary, the translator would see its explanation and previous translations.

Translation Assistant (our translation software) will scan the glossary automatically and would automatically highlight phrases found in the glossary. It would also let translators create new glossary items and consult the client about the meaning of key phrases.

Glossary and Search Engine Optimization

One of the most important things to notice when translating is search engine optimization (SEO). Even if you’re not translating a website, what you translate will most likely appear in some website somewhere.

It’s important to check what people are looking for and translate according to that. This would be good for search engine optimization and, generally, for getting more business.

When you begin translating, make a list of the main phrases in your application, that people might use to find you through.

The new glossary would be the perfect place to document these phrases and discuss their best translation with your translators.

What do you think? Any ideas for what a glossary should do?

Why we migrated to WordPress?

First, some background. Before that, our own site was built using a bunch of HTML files. It started as a few files (5), then gradually grew.

As we added more contents, we kept adding pages.

At some point in time, we semi-automated it by writing a Python script which managed the navigation. It created the top menu and breadcrumbs trail, but it still was a lot of work managing it.

For every update, we needed to rebuild everything, test and upload. This made us think many times before touching anything.

Then, came the translations…

We can translate sites built with static HTML files, but it’s not trivial. Whenever we update in one place, everywhere in 6 languages has to update. It’s a long and expensive process.

A CMS let’s us concentrate on contents

Any content management system (CMS) we would choose would be OK. The highlight of content management systems is that you only handle contents. The CMS handles the site’s structure.

Sounds trivial? It isn’t.

As you get more and more contents, organized into sections, managing the site’s structure becomes much more work than managing the contents.

Why we chose WordPress

We’re pretty fluent in both WordPress and Drupal. Drupal is an excellent choice for building complex sites. ICanLocalize.com mostly displays ’static’ contents, so WordPress pages do the trick fine.

WordPress, out of the box, includes most of the things we needed (pages, posts, categories and a great visual editor). Here are the plugins that we’re using to complete the picture:

WPML

our multilingual CMS plugin that allows running in several languages and creates the fancy navigation we’re using.

Support Tickets

A multilingual support ticket system that we use on our contact page.

Pods CMS

allows creating custom data types. We’re using it for testimonials throughout the site.

After The Deadline

a cool grammar, writing-style and spelling checker.

Akismet

filters 99% of the SPAM without bothering folks.

Lightbox 2

shows images in AJAX frames.

Smart Youtube

Allows embedding YouTube movies easily in posts and pages.

The move

Overall, it took 4 weeks and about $2500.

The new site is built using ThemeHybrid, which helped reduce the theme coding by at least 70%. Our child theme inherits all the CSS attributes and HTML structure, so we could spend our energy on our own stuff.

Tammy Hart did the graphics design for us, providing a solution which is both beautiful and functional (at least, we think so).

For us, it’s the first time we’ve split the work between a graphics designer and an expert programmer. It turned out great, as each could concentrate on what he (she) does best, without wasting time struggling with the other part.

In about 2 weeks we had the graphics design ready and it took another 2 weeks to complete the programming. Then, another few days to rebuild the contents (we took this opportunity to rewrite much of the site’s contents).

BTW, we documented some of the steps needed for ordering your own custom WordPress design.

Like the new site? Comments and suggestions are always welcome!