Sailing around the world

Posted: 03/22/2019 in Language

I started this blog in 2013 but after 5 years I’m taking an open ended sabbatical sailing around the world on my own sailboat.  I’m still doing some freelancing work for one small startup in silicon valley that allows me to pay my expenses, but I’m not actively looking for new clients.  The work life balance I have with just one client is perfect for now.

If you want to follow my adventures, you can go to


A few weeks ago I published a post on how to write and translate for Mobile, where I explained the three Fs approach: Fast, Focus and Fun.

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!

I finally found the time to test Heartsome Translation Studio on both my Mac and my PC. I carried out the most common tasks performed by translators:

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:

File               Edit

view               translation

project              database

QA              tools

advanced               help

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:

New                 languageTM                 termssource

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.


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:

Across Déjà Vu Lokalize Omega T Pootle WordFast
Alchemy Publisher GlobalSight Swordfish Omega T+ SDL Trados Studio Microsoft Helium
AnyMem gtranslator MemSource Ocelot Similis Microsoft LocStudio
Atril Déjà Vu Kilgray MemoQ MetaTexis Open Language Tools Star Transit Uniscape Translator Studio
CafeTran Lingotek MultiTrans Poedit Virtaal RC-WinTrans Translator’s

Read the rest of this entry »

Very interesting blog from a fellow JP-EN translator…

I’d like to close 2014 writing about one of the hottest topics: language plural and gender rules.  One of the issues I run more often into when I work on mobile apps is in fact the way developers handle plurals and genders.  I’ve had the opportunity to raise this issue with many apps developers and designers lately, and I was surprised to learn that unfortunately very few of them are aware of the complexities of other languages and the way to tackle this kind of problem.

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?

From the Norwegian Association of Literary Translators:

I’m constantly approached by developers working on new Mobile apps and by translators working on the localization of existing mobile apps asking me for guidelines and best practices on how to write or translate for Mobile. I’ve given the topic a lot of thoughts and I come out with the 3 magic Fs rule: No, the 3 Fs don’t stand for Francesco, Francesco and Francesco; they stand for Fast, Focus and Fun.

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.


1. Keep it brief.

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

Read the instructions that came with your phone.

2. Keep it simple.

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

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

3. Be friendly.

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

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

4. Put the most important thing first.

noTask last
Tap Next to complete setup.

yesTask first
To complete the setup, tap Next.

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

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

yesShort 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

Go to Intl. settings.

yesSpelled 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.

The Italian Literary translators are struggling. Please help them by signing this petition.

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

Try to ask this question to several stakeholders and you would be surprised about how many different answers you will get.

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!