If you want to follow my adventures, you can go to http://www.sailingoroboro.com

Some readers asked me how you can possibly be fun when you design something serious as say, a payment flow. Well, here’s an excellent example from what I consider the best app out there in terms of sleek design and crisp content: Hotel Tonight.

Hotel Tonight is a San Francisco’s startup founded in 2010 by Sam Shank, Jared Simon and Chris Bailey. It’s in series D founding round, backed by VCs like, among others, Accel Partners. It’s only on Mobile, their website is just a homepage where you can download the app.

Check out how creative and fun they have been with the Terms and Conditions button: Where everybody else puts a boring button or checkbox to tap, designers at Hotel Tonight come out with this innovative and fun way: You need to trace the contours of their logo with your finger to agree to the terms and complete the booking:

If there’s an app out there that abides by the three principles I’ve listed in my previous post, this is Hotel Tonight.

Take a look at how fast and focused their content is: The Why We Like It section, for example, only contains 3 bullet points, and at least one of them always says something fun about the hotel:

When I’m asked for examples of well designed apps with great content, tone of voice and style, Hotel Tonight is the first (and finest) example that comes to my mind. Oh, and one more thing! The app works really well and the deals are fantastic!

Please feel free to post other examples of apps with sleek design and great content!

1) Create a translation project importing a xlif and an MS Word file.
2) Create a new TM and import an existing one in both TMX and TXT format.
3) Create a new TD and import an existing one in TBX format.
4) Translate the assets.
5) Search a term in TD and TM.
6) Observe TM and TD results.
7) Run a concordance search.
8) Run the spellchecker.
9) Check numeral and tags consistency.
10) Export the assets.

So, first the good stuff:

Unlike all other commercial tools available today on the market, Heartsome Translation Studio runs on a Mac! The User Interface is very sleek and the views can be customized according to your personal preferences. The translation happens in a grid, like in Trados, Déjà Vu or MemoQ. The segment’s filter offers a good number of options and it can be customized. The toolbar is not too crowded with unnecessary options.

Here’s how the UI looks like:

Everything works as expected. Navigating through the segments using the up and down arrows is simple and fast. The concordance search in the TM and TD works well, although it’s a bit slow. Keep in mind that the TM I used for the test is fairly large, it contains 210,793 entries. Whereas the glossary contains about 2,000 terms. Also when navigating through the segments in the translation grid, it takes almost 1 second to see fuzzy matches appear in the Translation Memory window. As a reference, I’m testing the tool on my MacBook Pro with OS X version 10.9.5, a 2.6 GHz Intel Core i5 and 8 GB 1600 MHz DDR3. I also tested it on my PC, a Windows 7 with Intel Core i7-4600U and 8 GB or RAM. So the slowness is definitely not due to outdated hardware. But I wouldn’t say that the speed is a limiting factor. After all, the TM I’m using is unusually large. This is kind of a stress test. Hotkeys and shortcuts are fully configurable, you can add different TMs and TDs, you can run easy QA checks for numeral and tag consistency, display either all segments or use pre-defined or custom filters, insert comments at segments level and so much more. You have all the option you would expect from a modern CAT tool. Here’s an overview of the toolbar’s menus:

Heartsome Translation Studio also provides you with an added bonus: a very useful set of plug-ins:

• CSV to TBX Converter
• CSV to TMX Converter
• MARTIF to TBX Converter
• TMX to Trados TXT memory file Converter
• Java Properties Viewer
• RTF Cleaner
• TMX Validator
• XSL Converter

This tools work very well and are quite handy.

And now the bad stuff:

Opening a project exported from WorldServer in xlif format is not as a simple task as it should be.  Well, first of all you are forced to create a translation project going through the wizard. I wish I could simply drag and drop my .xlf project in the editor and have the program open it up for me.  But that’s not possible at the moment, so you have to go through the wizard:

What the developers didn’t realize here is that translators often need to work on several project a day, and if you add up all the time you waste in going through this wizard, it’s just unproductive.  The other thing that I don’t like is the overly complicated folder structure where your assets are saved:

Practically your projects are saved in this default position: C:\Users\username\Heartsome Workspace\, where you have the folders Intermediate, Source, Target, XLIFF. I mean, is not as bad as Trados Studio, but there’s got to be a more intuitive way to handle this. Another way to open a file for translation, is by dragging it directly into the Source folder under the specific project. I hope that someone is going to simplify this process.

Another annoying behavior is the Export feature. When you’re done with your translation/review and you need to deliver the project back to the requester, you need to click on Project > Export Project and then select the path where you want to export a funky .hszip file, that is nothing more that a zip archive that needs to be renamed into .zip to be opened and that contains a Xliff folder with the .hsxliff file.

Conclusion:

Overall, Heartsome Translation Studio is a very good tool that could potentially became an excellent one with some simple User Experience improvements.  At the moment there’s only one contributor on GitHub, but it’s true that this tool become Open Source just a few months ago.  The UI looks sleek and the tool is robust (never experienced a crash).  It has lots of potential, and could easily take over Trados Studio if more developers start contributing.  So watch out for Heartsome Translation Studio in the future!

In my next post I will be reviewing Omega T+.  Stay tuned!

No, this post is not about Caterpillar CATs, it’s about the so called Computer Aided Translation tools  But there are so many analogies between the heavy industry and our industry that I wanted to use their logo…

I took the time to compile an extensive list of CAT tools available on the market today, both commercial and Open Source. The goal is to compile a gap analysis and a comparison review.

Here’s the list of CAT tools:

Among all these CAT tools I decided to install and test 11 of them. Here’s the list of the CAT tools I tested:

I also took the time to compare the different license costs:

Among the criteria I used for this comparative analysis:

• State of the art TM and TD technology.  In other words,  is the TM able to automatically propose relevant translations from the Translation Memory as a complete (“exact match”) or partial solution (“fuzzy match”) whenever the same or a similar sentence occurs in the project and also automatically detect glossary terms in the Terminology Database?
• Project-level views and operations.  For example, is it possible to open a batch of files as if they were just one big file to boos productivity? Can you easily add TMs/TDs, and import and export assets?
• State of the art Multilingual Editor.  In other words, is the editor user friendly and productive? Can you easily customize it to your needs?

I’ll start the comparative review with the first of the three Open Source tools: Heartsome Translation Studio. Stay tuned!

In my opinion, it is paramount for Mobile developer and designers to think ahead about their global audience and build these language plural rules in their apps since the very beginning.  I’ve been insisting a lot on this, because internationalizing the strings of their apps retroactively is a lot more work than doing it incrementally throughout development.  And more costly too.

Language rules
So what exactly are these Plural Rules?  Let’s take this example:

You need to count the number of people following you.  In English you can get away with 2 strings:

X followers (when X is equal to 0 or more than 1)
X follower (when X is equal to 1)

Imagine your app suddenly becomes a hit oversea, for example in Russia.  You need to localize it and you send your string files to the Localization team.

If you’re Localization team is a good one, they will tell you that you can get away with that quick one/not one check when pluralizing nouns.  These are the only two categories in English, but other languages aren’t that simple.  Your Russian users have 4 different rules for pluralizing their nouns!  And if you think this is complicated, Arabic speakers have six!

If you want to learn more about plural rules, you can read the Unicode Common Locale Data Repository (CLDR) Project which provide tables and charts that can help developers to handle these cases.   The category names (i.e. zero, one, two, few, many, and other) are common across all languages and the rules define the mapping between a quantity and the plural category to use.

For example, for English we would use:

one ⇒ i = 1 and v = 0 (where i = integer value and v = number of visible fraction digits)
other ⇒ No rule, or any other number.

But for Russian, we would use:

one ⇒ v = 0 and i % 10 = 1 and i % 100 ≠ 11
few ⇒ v = 0 and i % 10 = 2..4 and i % 100 ≠ 12..14
many ⇒ (v = 0 and i % 10 = 0) or (v = 0 and i % 10 = 5..9) or (v = 0 and i % 100 = 11..14)
other ⇒ No rule, or any other number.

Gender Rules
To correctly support gender in languages you can follow a similar pattern to the Plural Rules. English has three options: Male, Female, and Neutral (Modern English retains features relating to natural gender, namely the use of certain nouns and pronouns, such as he and she). Polish has five! Yes, five! (Feminine, Neuter, Person-masculine, Animate-masculine, Inanimate-masculine).  And because there’s so much variation across languages, systems like the CLDR just assign each gender a number:

• 0 for male
• 1 for female
• 2 for neutral

Apple’s Localizable.stringsdict

In the past there wasn’t any option for properly internationalizing your iOS app.   The good news is that in mid 2013, Apple released Localizable.stringsdict that provides built-in support for plural and gender rules in the Foundation Release Notes for iOS 7 and OS X 10.9.

If you start to use these categories even before you need it, you will be able to reach a global audience faster than you would otherwise, saving yourself a lot of work, time and money!

What’s there not to like?

When writing for mobile, keep in mind the intended audience: mobile users have less time and shorter attention spam than regular web users. And they want to have fun. So here it goes:

1. Fast: Keep it brief. Be concise and precise. Try to use the same number of characters as in the English source (including spaces), and don’t use more unless absolutely necessary. Describe only what’s necessary, and no more. Don’t try to explain subtle differences. They will be lost on most users.

2. Focus: Keep it simple. Pretend you’re speaking to someone who’s smart and competent, but doesn’t understand technical jargon. Use short words, active verbs, and common nouns. Put the most important thing first. The first words in a sentence should include at least a hint of the most important information in the phrase.

3. Fun: Be friendly. Talk directly to the reader using second person “you”*. If your text doesn’t read the way you’d say it in a casual conversation, it’s probably not the way you should write it. Don’t be abrupt or annoying. Make the user feel safe, happy and energized. Don’t use abbreviations to shorten a word or a phrase. Abbreviations as a shortcut for space restrictions must be avoided at all times.

Examples:

1. Keep it brief.

Too formal
Consult the documentation that came with your phone for further instructions.

Preferred
Read the instructions that came with your phone.

2. Keep it simple.

Confusing
You cannot perform this action with this app because this feature is not supported for your country. Please use the main website instead.

Crystal clear
This feature is not supported in your country yet. Please use the website.

3. Be friendly.

Confusing
Sorry! The app is not responding. Please close it and reopen it.

Shorter, more direct, no fake apologetic
The app isn’t responding. Please restart.

4. Put the most important thing first.

Task last
Tap Next to complete setup.

Task first
To complete the setup, tap Next.

5. Describe only what’s necessary, and no more.

Too wordy
The app needs to communicate with our servers to sign in to your account. This may take a few moments.

Short and to the point
The app is connecting to the server. This can take a few moments.

6. Don’t use abbreviations to shorten a word or phrase

Abbreviation
Go to Intl. settings.

Spelled out
Go to International settings.

Being fast means that features are fast to use, therefore the text needs to be fast to read. Focus is about simplicity, therefore the text needs to be easy to read. Fun is about engagement, therefore text needs to be friendly.

Here you can find an interesting interview (in Italian) to Marina Pugliano, Yasmina Melouah and other Italian Literary translators:

Some may say that quality is measured by the user experience and that a quality localized product is one that functions the same way as the English version.

Others may say that a quality translation is one that maintains brand consistency.

Or that a quality translation is one that is factually accurate, readable and (hear hear) not localized (preserves the source culture nuances).

I find all the above answers valid.

However, in June 2006 a new translation quality assurance standard was published by ASTM International and unfortunately it’s still relatively unknown: ASTM F2575.

The ASTM translation standard (F2575) defines translation quality as:

The degree to which the characteristics of a translation fulfill the requirements of the agreed upon specifications

This definition implies two stages: Agreeing upon project-specific specifications and applying those specifications. Sounds too easy, doesn’t it? But it actually works! This approach can be applied to every translation project.

How? Well, translation projects usually consist of three phases:

Pre-Production, Production and Post-Production (aka Post Mortem).

It’s in the Pre-production phase when you should discuss and agree upon the specifications. In the Production phase, these specification should be applied. Finally, in the Post-Production phase, you should carry out the project analysis to verify the fulfillments of the agreed upon specifications.

If all translation projects followed this simple approach, all the different stakeholders would be much happier at the end of the project!