Archive for the ‘Business’ Category

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:

IMG_2806
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:

IMG_2807

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

wiritingformobile
Examples:

1. Keep it brief.

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

yesPreferred
Read the instructions that came with your phone.

2. Keep it simple.

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

noConfusing
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

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

When designing a mobile app, one of the things a designer should keep in mind is translated text expansion. Probably this doesn’t come as something new; there’s a whole literature on the subject.

However, when designing and localizing a mobile app you should also avoid other layout tricks that as a designer you might be tempted to try. I recently stumbled upon an app for iPhone that struck me for its peculiar use of ellipses.

What are ellipses? As a convention, ellipses in UI text are used in the following cases:

  • To indicate that a command needs additional information.
  • To indicate that text is truncated.
  • To indicate that a task is in progress (for example, “Searching…”)

Italian

Japanese

Normally, when the translated text expands too much, the designer would use an ellipsis at the end of the sentence.

In this case Italian expands by approx 40%. Japanse seems to be aprox the same lenght as the English.

English: New message (11 characters)
Italian: Nuovo messaggio (15 characters)
Japanese: 新しいメッセージ

The funny thing is that in this specific app, the designer used an ellipses in the middle of the text, and not at the end where it should normally be.

As a result, the meaning of the Italian translation is not “New Message” but “New essay”. That’s what “saggio” means in Italian.

Why the developer didn’t stick to widely accepted conventions on the use of ellipses? This is still a mystery to me.

I’ve never been a big fan of ellipses used to indicate that a text is truncated. I believe that a better practice would be to implement the convention of scrolling text. Like a ticker message that scrolls across the screen letting the user read the entire string from beginning to end. On mobiles, this is used a lot in lists in the body of a window. And while I haven’t seen it used in the window title of an app, it would be a worthy experiment for design engineers to figure out.

Food for thoughts. What’s your take?
 

 

What is quality in translation? This question is inevitably raised every time I go to a conference or a meet-up in the translation industry. I believe that in order to be able to answer this question we should first define what is a good translation. Sometimes progress in a discipline can only be made if the right question is being asked.

Although there are different schools of thought on this subject, many have argued that a good translation is one that conveys the same meaning of the source text.

However, this claim inevitably leads to the question, what is meaning? Linguists (and philosophers) have debated over this question for centuries without reaching an agreement.

I believe that meaning doesn’t only depend on the source text but also on the interaction with the intended audience, the purpose of the text and the specifications.

Audience and purpose of the text:

Playing on the tradition in elementary schools of having troubled students write a phrase several times on the blackboard as punishment, an American advertising company thinks of the phrase Do not tell lies repeated many times, for an ad about a copy machine for the US market.

After they run the ad in the US, they decide to use the same poster for the Japanese market and they ask a translator to translate the sentence into Japanese without any context or explanation. The translator returns a perfectly acceptable translation: 嘘をついてはいけません

Problem: in Japan, writing a phrase on a blackboard many times as a punishment in front of the entire class is not a common practice.

Result: the Japanese people who saw the ad were puzzled and did not understand it.

Therefore, if you ask me if “嘘をついてはいけません” is a quality translation of the source text “Do not tell lies”, the answer is yes. However, if you ask me if the Japanese translation fulfills the purpose of the source text, the answer is no.

In this case, the appropriate Japanese translation would probably have a Japanese (not necessarily a student) laboriously copying some phrase by hand, in a context that makes Japanese people think that a copying machine would be a good idea.

The example above illustrates why audience and purpose of the text are critical in translation. It also explain why specifications are equally important: The translator wasn’t given the correct instructions and did not know the conditions into which the translated text was being released.

Based on these considerations, the answer to the initial question of this post “What is quality in translation” is the following:

Translation quality is the degree to which a translation complies with the requirements of the agreed upon specifications.

ASTM F2575-06
The approach of agreeing upon project-specific specifications and applying those specifications is also implemented in the ASTM Standard Guide to Quality Assurance in Translation and Localization (published in 2006 as ASTM F2575), and is intended as a standard for the American translation industry. As the document’s name suggests, it is a guideline, informing stakeholders about what basic quality requirements are in need of compliance, rather than a prescriptive set of detail instructions for the translator.

Francesco Pugliano