Posts Tagged ‘iOS’

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?

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.

 


I’m always very happy when I stumble upon a piece of software with nicely executed localization and today I want to share with you one of the most noticeable example that can be found in Apple iOS 5.

Here is the Setting screen of the iPhone in English:

How would you localize that On/Off switch in other languages?

Easier solution: just translate!

Would that work in Italian? Maybe, if you reduce the font by a lot! Not the best experience for the user though!

But would that work in other languages? Probably not!

To prove my case, here is the German translation of the switch. As you can see, Aktiviert would barely fit, whereas Deaktiviert definitely doesn’t fit:

Smart solution:

Well, at Apple they realized that it was going to be very hard to accommodate that switch in all the languages supported by the iOS. Hence, they decided to change the design of the switch itself for the international markets and use the convention I/O:

I personally believe that this a fine example of implementation driven by localization.

Francesco Pugliano