Presented by: Jon RitzdorfMarch 22, 2012

Webinar: Software & Mobile App Localization

Webinar Tips

Minimize control panel

To ask questions use “Questions” area

s2

Slide 2

s2 Only use this slide if we're using GTMsengelsen, 3/19/2012

Presenter

Jon RitzdorfGlobalization Architect

Agenda

> Understanding Internationalization• Common Challenges & Solutions• “Global Readiness” Testing

> Localization Process• Preparation• Translation/Review• Testing

> Checklist> Q & A

UNDERSTANDINGINTERNATIONALIZATION

Illustrating InternationalizationWe “color” everything with our cultural norms

• Internationalization (i18n):Priming the walls to accept any color

• English becomes “just another language”

> Focused on enabling your software to support global markets

…without engineering changes to the core

application each time you add a market!

Internationalization

Two Core “Enablements”

1.Language

2.Locale

Language Pitfalls

> The most critical of all issues

> Results in user abandonment of software

Strings & Display Input & Output

Collation & Sorting Search

Language

Strings: Externalization> Ideally, software strings are all “externalized”

in a “resource format”

messages = ResourceBundle.getBundle(currentLocale);System.out.println(messages.getString("greetings"));System.out.println(messages.getString("inquiry"));System.out.println(messages.getString("farewell"));

greetings= Hello. inquiry = How are you?farewell = Goodbye.

Content in resource file separate from code

Shared code

Content in language X

Content in language Y

Content in language Z

greetings= Olá.inquiry = Como você está?farewell = Tchau.

greetings= 你好。inquiry = 你好嗎？farewell = 再見。

Display: Expansion

> Give ample whitespace for UI controls (20-50%+ vs. English)

Close

Schließen20 - 50%

Browse…

Durchsuchen…

Display: Fonts & Corruption> Ouch! It was supposed to be Korean…

No font support

Corrupted

Input: Alphabetic LanguagesEuropean Korean

Input: East Asian

Input Method Editors (IME)• An “interpreter” between your typed output and

the input that is entered into the system

to point to

to stab

to insert

to hold up, to offer

to shine on

to color,to pour into

指す

Input: Support> Do all your input fields accept natural keyboard

input for your desired language(s)?

Four Solutions for Language

1. Use interface fonts that support multiple languages

2. Use “Unicode” throughout

3. Flexible UI layouts orprovide length limitations

4. Test for real language input

Locale Pitfalls

> High “annoyance” factor

> Will be frustrating or offensive to the user, but it is still possible to use the software

Dates, Time & Calendars

Personal Data Conventions

Number & Currency

ConventionsIcons/Graphics

Locale

03/01/12USA: March 1, 2012France: January 3, 2012Japan: January 12, 2003Taiwan (Political): January 12, 1914

Dates

> First day of the week?

Calendars

Sunday

• Americas• East / SE Asia

Monday

• Most of Europe

Saturday

• Middle East

Times, Numbers & Currencies

12-hr. or 24-hr.

Comma , period or space ?

Unit orcurrency conversion?

> Easy to fit a name into a compartmentalized data structure of 2 or 3 separate parts

Personal Data: Names

Family nameGiven name

Personal Data: Names

China & Japan

2-5 characters, cannot be broken up, might have English and/or

romanized name too

李振藩(Lee Jun-fan)

本田 宗一郎(Honda Sōichirō)

Bruce Lee

Hungary

last name first, no such thing as

“middle names”

Kovács Júlia

Malaysia & Indonesia

Anything goes, even given names with no

family name

Fam Khiuk Yen

Finy Wirawan

Suharto

Megawati Soekarnoputri

Four Solutions for Locale

1. Know target languages and locales before development

2. Identify culturally specific areas in your app

3. Rely on existing APIs for date/time/number support

4. Get familiar with the conventions of the target locales

SSN:

中文Français

Test the language and locale support of your software before going too far along

“Global Readiness” Testing

Cosmetic Testing

Linguistic Testing “In-context” language verification within

runtime UI

cosmetic UI checks; locale-specific

functional checks

LOCALIZATION

locale & language-neutral support

INTERNATIONALIZATION

Global Readiness Testing

Global-Readiness TestingLooking for the

ability of software to:

• Adapt to user locale preferences in target market(s)

• Adapt to user language preferences for intended market(s)

• Accept, parse and output language data for intended market(s)

LOCALIZATION PROCESS

Illustrating LocalizationAdding local “color” to our primed walls

• Localization (l10n): From the blank wall you create Chinese, French, Turkish …English!

• Remember, English is just another language!

Localization> After internationalization> Focused on adapting your software

to support local markets> Creating a “look and feel”

appropriate for a specific market

Localization: In Three Steps

1 Plan

Deliverables

File Formats

Release & Update

Schedules

2 Translate/

Review

Cultural Assessment

Resources

Language Assets

3Test

Setup

Build

Cosmetic & Linguistic QA

What needs to accompany the software?• Release notes, EULA, “ReadMe”, Help system,

Wiki, Documentation, Quick Guide, Packaging?

Local requirements?• Required by law that software/firmware sold

in the target market be accompanied by {x}?

1. Planning Deliverables

1. Planning File Formats

Software strings are ideally delivered in a “resource” file specific to the platform

Platform (Programming/Scripting Languages) Resource

Microsoft - Win32 (Visual C++, VB 6) .rc

Microsoft - .NET (C#, VB.NET, ASP.NET) .resx

Java (Java/JSP) .properties

Open-Source (Python/Tcl/awk/Perl/PHP) .po

Ruby on Rails .yml

Databases .csv, .xml

DB

1. Planning Release Schedule

German finalized and

released

English released

French finalized and

released

Staggered/Consecutive Release

French, German and Italian released with the English

Simultaneous Release – “Simship”

French, German and Italian released

English released

French, German and

Italian started

Delayed Release

1 month

1 week 1 weekItalian

finalized and released

1 week

English schedule = international?

• Cyclical (“Waterfall” Dev.)Ex: two releases per year

• Rolling (“Agile” Dev)Ex: {x} updates per year, every 2 weeks or so

• Sporadic/Random (“Ad hoc” Dev.)Ex: on request from your customers

1. Planning Release Schedule

Cultural considerations?• Review UI images/icons esp. for Mobile!• Does the icon make sense outside of the USA?• Cultural, political or religious interpretation?

2. Translation/Review Culture

Who will translate & review the content?• A language vendor• Internal employees• Former employees• Trusted end-users• Resellers• Combination

2. Translation/Review Resources

Glossaries? Style Guides?

Is this a gadget, doohickey, thingamajig or contraption?

2. Translation/Review Assets

Formal: “Proceed”Casual: “Next”Intimate: “Rock On!”

What “register” does your international

audience use?

Recyclability of translations for updates and future product releases?

• Translation Memory• Terminology Databases

2. Translation/Review Assets

Platform, OS, Browser: Localized versions?Hardware and firmware?

3. Testing Setup

Builds and versions can get complicated very quickly

COMPILE

Localized“Resource” file

“Build” Tree = C#.NET

Localized“Binary”

3. Testing Builds

The UI of software must be checked “in context” per language to catch any bugs

“Global Readiness” Testing

Cosmetic Testing

Linguistic Testing “In-context” language verification within

runtime UI

cosmetic UI checks; locale-specific

functional checks

LOCALIZATION

locale & language-neutral support

INTERNATIONALIZATION

3. Testing Cosmetic & Linguistic QA

Pre-handoff

Test pass(es) for potential internationalization issues completed beforehand

All software strings “externalized” to resource formats

Clear on what is to be sent for translation

Clear on language & QA stakeholders

“Going Global” Checklist

Handoff

Include only what is relevant for translation

Demo version of the English app for reference

Special Instructions (as needed)Examples:

String length limits Build instructions

“Going Global” Checklist

Testing

Set up? Platforms, OSes, browsers, localizations? Who does what?

Scope? language-focused test script user test cases

Bug tracking/logging?

“Going Global” Checklist

Conclusion

1. Know your markets and their respective languages and cultural conventions

2. Internationalization 1st, Localization 2nd

3. Make sure you have defined everyone’s role in the overall process(i.e., who does what?)

QUESTIONS

ResourcesTop 10 Software Localization Tipshttp://www.acclaro.com/software-localization-tipsTop 10 Mobile App Localization Tipshttp://www.acclaro.com/mobile-application-software-localizationTop 10 Software Globalization Testing Tipshttp://www.acclaro.com/software-globalization-testing-tipsSoftware Localization Blog Postshttp://www.acclaro.com/translation-localization-blog-category/software

Jon RitzdorfGlobalization Architectjritzdorf@acclaro.com914-433-4908Based in Irvington, New York

Software/Mobile AppsWebsites

DocumentationMarketingMultimedia