When we introduce something new, we write about it and we also like to show it in action. There’s nothing better than a short demo movie to explain how things work.

For example, last week we added a new major feature to our system (a translation glossary). To use it properly, translators need to see exactly where to click and what to expect.

So, I wrote a short blog post about it, included a 3 minutes video and we’re all set. About 1000 translators viewed it and a week later, they’re all using the glossary correctly. I’m happy.

Our setup for web videos

It’s a bit of a long chain, so here goes:

1. Produce the video: I’ve use both Instant Demo, Jing and Camtasia Studio.
2. Upload to Amazon S3 and make it available for all to read.
3. Create web access via Amazon CouldFront for that S3 bucket.
4. Install a Flash movie player on your server. We use JW Player.
5. Embed videos in your site.

And now, the full details…

1. Producing videos

No matter what you use, at the end you need to have a movie file to play. The best is to get an FLV or MP4 file. Inside, they’re pretty similar.

There are a few programs that can help you produce videos. Eventually, we settled on Camtasia Studio. Editing is very convenient and it makes it easy to record a sound track and then add video. If your own voice is good enough (so that you don’t need to get professional narration), Instant Demo will be an excellent option as well.

When you’re done producing the video, get an FLV or MP4 file.

2. Serving videos from Amazon

Amazon S3 quietly became a leading option for remote storage. Their CloudFront system also makes them an excellent choice for a simple Content Delivery Network (CDN).

If you’re not familiar with the terminology (just like I was 3 weeks ago), a CDN is a network of servers, placed in different locations, who can deliver the same contents.

The idea is to deliver large files from a server that’s closest to the client. Pretty simple to explain, but requires serious infrastructure. Apparently, Amazon’s solution is very good.

To get started, you will need to create an account for both Amazon S3 and CloudFront. Head over to Amazon Web Services home page where you can read more about all their services.

2.1. Storing files in Amazon S3

You will need some sort of interface program to store files on Amazon S3. I use the Firefox extension S3 Fox. It’s like a tiny FTP program that allows you to create buckets (S3 top-level directories), store files and read them.

S3 Fox Firefox extension

Steps:

1. Log in to your AWS account.
2. Create a new directory (will create an S3 bucket).
3. Go to that directory.
4. Upload the file.
5. Select the file and click on the Edit ACL button.
6. Make it readable by all.

3. Enabling CloudFront access to your S3 files

Now that the files are in S3, you need to add the CloudFront access.

Go to your AWS account and click on the CloudFront tab. Then, click on Create distribution.

CouldFront new distribution panel

You can choose between Download and Streaming.

Download means your files will be served like regular HTTP downloads (like files that you download normally to your browser).

Streaming means files will be sent in small chunks to the client. The advantages in streaming distribution is that clients can quickly skip ahead. Downloaded files need to be read from start to stop.

The Flash display component can read just fine using both delivery methods. I’ve seen a dramatic speed difference between the two. The Download delivery worked way faster than the Streaming delivery. It could be a result of other factors, but we’re using only Download at the moment.

The CNAME is an optional field. It will allow accessing the files from a name in your domain. We don’t use it, as nobody needs direct access to downloading our videos.

Before you continue, test it. Open a browser, point it to the distribution you’ve just created and the file that you uploaded. Your browser should download/play the video.

Note: the CouldFront distribution that you create is for an entire Bucket (top-level directory). It will allow serving all the files that you upload to it.

4. Installing a Flash player

A Flash player is the piece of code that sits between the files (in Amazon) and the browser.

It’s a Flash program, so it runs on the visitor’s browser. It reads the movie from the web, adds playback controls and displays the movie on the screen.

We use JW Player. It’s a simple and lightweight player and also includes tons of plugins, which we still haven’t started exploring. For basic video playback, you just need the player and nothing more.

1. Download the player.
2. Unzip it on your web server.
3. Run the sample clip and see that everything works.

Now, you have your own Flash player and you can play any movie in your site (not just the demo that came with the player).

5. Embed videos in your site

JW player comes with a handy setup wizard that will allow you to create the HTML code for your own movies.

You’ll get a piece of HTML that you can just copy/paste to your site.

I preferred to edit the HTML code directly, without using the wizard. After two rounds, it works faster for me than going through the web wizard just for changing a couple of parameters.

Here is a sample HTML code for our own video (that Glossary how-to):

<script src="http://www.onthegosystems.com/mediaplayer/swfobject.js" type="text/javascript"></script>

<div id="mediaspace">This text will be replaced</div>

<script type="text/javascript">// <![CDATA[
var so = new SWFObject('http://www.onthegosystems.com/mediaplayer/player.swf','mpl','640','467','9');
so.addParam('allowfullscreen','true');
so.addParam('allowscriptaccess','always');
so.addParam('wmode','opaque');
so.addVariable('file','http://d1ftqtsbckf6jv.cloudfront.net/using_glossaries.mp4');
so.write('mediaspace');
// ]]></script>

Note: this script assumes an ID with a name. If you’re embedding more than one video on the same page, you’ll need to use the HTML code directly and not this cool JS.

This code uses JW Player’s JavaScript to create the HTML. It’s a smart thing. Different browsers support different HTML to play videos. Instead of creating an overly complicated HTML that runs on all browsers, you’ll get the minimal code per browser.

And you’re good to go!

Here is this code running live:

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!