Home » Blog

Finally, a Glossary

It’s taken a while to build, but it’s finally ready – a global translation glossary for each client.

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.

This text will be replaced

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>

Better translation for iPhone apps and short texts

We’ve given our text resource projects a major update, to make iPhone and text translations easier and better.

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.

Continue reading “Better translation for iPhone apps and short texts”

Translation glossary for all project types

In order to allow more consistent translations, done by several translators in parallel, we’re going to add a translation glossary, per client.

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.

Continue reading “Translation glossary for all project types”

ICanLocalize.com is using WordPress

It was hard work, but it’s definitely worth it. We’re now using WordPress as the content management system for our own icanlocalize.com.

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.

Continue reading “ICanLocalize.com is using WordPress”