Localisation Resource CentreSummer School

Introduction to LocalisationJohn Malone

Agenda

• Definition of Localisation

• Localisation Process and Schedule

• Localisation for the WEB

• Issues and Considerations

Localisation. What is it?

• Process

• Language

• Culture

Localization

Localization is the process of creating or adapting a product for use in a specific target country or specific target market.

S.I. Hayakawa

No word ever has the same meaning twice.

To insist dogmatically that we know what a word means in advance of its utterance is nonsense. All we can know in advance is approximately what it will mean.

How about Culture?

• Are there efficient ways to describe cultural differences?

• Or are we encouraging a sophisticated stereotyping?

Culture Red Yellow Green Blue

Europe/West Danger CautionCowardice

SafeSour

MasculineSweetCalmAuthority

Japanese AngerDanger

Grace-nobilityChildhood-gaiety 

FutureYouthful- energy

Villainy

Arabic   HappinessProsperity 

Fertility-strength

Virtue, faith, truth

Chinese Joy-festivity HonorRoyalty 

   

Let’s examine a simple matter like colour

Localisation: A closer definition

• General localization focuses on superficial cultural differences . . . like language, currency formats, date and time formats

• Radical localization focuses on cultural differences that affect the way users think, feel, and act, (including) learning styles

Micklethwait & Wooldridge:

The idea that most of the same productscan be sold everywhere in the same wayhas been thoroughly discredited.

Cultural Context

• High-Context Cultures rely less on the message than senders/receivers

• Low-Context Cultures rely on detailed, unambiguous messages

Continuum of Context (Hall)

Chinese Japanese Arab Greek Spanish Italian English French American Scandinavian German German-Swiss

High Context

Low Context

Cultural MappingHofstede’s Value Dimensions

• Individualism-Collectivism

• Uncertainty Avoidance

• Power Distance

• Masculinity/Femininity

Hofstede:Individualism-Collectivism

Importance of people’s personal goals versus the goals of the group• Individualistic Countries: U.S., Australia,

U.K.• Collective Countries: Japan, Pakistan,

Taiwan

Hofstede: Uncertainty Avoidance

Importance of predictability and order (avoidance) versus willingness to take risks and work without rules• High-Avoidance Countries: Portugal,

Greece, Japan• Low-Avoidance Countries: Sweden,

U.S., Finland

Hofstede: Power Distance

Belief in hierarchy and authority versus the belief that power should be distributed• High Distance Countries: India, Brazil,

Greece• Low Distance Countries: Austria,

Finland, Israel

Hofstede: Masculinity/Femininity

Assertiveness, ambition, and achievement (masculine) versus nurturing and caring (feminine)• Masculine Countries: Austria, Venezuela,

Japan• Feminine Countries: Scandinavia,

Netherlands

Localisation Process

• Schedule (cradle to grave)

The Master Schedule

Planning

Specification

DevelopmentStabilization

GoalsClosure

Milestone 0

Spec Complete

Code Complete

RTM

Spec/SheduleIterations

Design Changes Triage

Overview

• How to ship quality software on time–Setting the vision–Scheduling–Resource management–Tracking –Corrective actions

Successful Scheduling Includes...

• Setting the schedule.• Calibrating the schedule.• Agree on the tracking criteria.• Understanding dependencies.• Reaching milestones.• Creating backup plans.• Changing the schedule.

Dates and Milestones

• Goals and Vision required for dates to have meaning

• Identifying and setting key dates

• What makes a good Milestone

• Identifying Dependencies

• Planning for the Unplanned

• Agent for Change

• PM’s role?

Keep it General - Get Buy-In.• Capture the major milestones:

– Planning Research Complete– Goals and Vision Closure– Spec Drafts and Completion– Spec Inspections– Dev Schedule Complete– Dev Milestones (M1, ZBR, Betas)– Code Complete– RTM

• Choosing dates: art vs. science.• Give every milestone a purpose. Know how to

measure if you met it.

The Development Schedule

• Another set of CRITICAL milestones.• Aggressive but realistic.• Reflects key Dev milestones Don’t forget:

vacation, meetings, sick time, integration, overhead, dependencies

• Buffer – know how to use it.• The Dev schedule is the critical tool to ensure the

right product is shipped at the right time.

Identify Key Dependencies

• Who are they?–Dev Team–Component owners–Hosts Products–Project teams - test, UA, build

• PM’s Role• To identify them• Establish key relationships

Project Management (Chaos is the natural state)

• Planning

• Preparation

• Scheduling

• Communication–status meetings, aliases etc.

(A project in Crisis)

• RTM looms

• Postponement Freefall

• How to stop

• “Just don’t do it”

• PM’s Role?

Remember this is normal!!

Must Haves for Success

• Communication

• Requirements sent to Development

• Flexibility–From vendors–From component owners–From internal teams

Ongoing measures

• Setting requirements with Dev team

• Measure costs of change and present to management

• Deliver spec’s on requirements for localisation

• Costs Savings and Shorter Delta’s!

Hit and Track Milestones - RTM Rehearsal

• Focus team on next milestone. • Know the criteria to measure if you made it –

weekly bug goals, dependencies etc.• Milestone not complete until criteria met. • Don’t start the next milestone until finished

with the previous one – accumulated slip. • Cause team to make trade-offs – consensus

and buy-in.

.

Dependencies cont.

• How to prevent problems?–Document shared goals and vision–Understand other’s commitments and

schedules–Have clear contacts and owners–Don’t assume “can do” is the same as “it’s

done” –Follow through to closure – sooner is not

always better

Achieving Milestones

• Why have Milestones?–Motivation–Evaluate progress and take corrective action–Rehearsal for the RTM

• What is PMs role?–Leader responsible for delivering on dates–Hub for project group

Successful Milestones

• A milestone is more then a date

• Give clear measurable targets to aim for

• Clear Milestone priorities and criteria

• How do you know when it has been achieved?

• Getting Closure

• Moving on

Refining Schedule/Product

• Cut early - Stay focused on product goals. Is the feature still usable after the cuts.

• Low pri late task cut candidate.• Ensure dev estimates become more “sure” for

future tasks: prevention vs. reaction.• Track Feature Changes Closely

Changing the Schedule

• Critical Role of PM: Push Back.

• Consider ALL other alternatives: Cut features, simplify designs, more resources, work harder/more.

• Know the costs – marketing, testing, support etc.

• Communicate with management and with dependent components.

Critical Milestone: Code Complete

• All features implemented to a measurable and agreed level of quality -- scenarios to test against.

• Primary benefit: full stabilization begins.

• Focus turns from Development to Testing.

• Warning signs: “We’ll complete feature X after code complete.” Understand the risk.

Localisation for the WEB

• Essential Differences

• Quality, turnaround

• Infrastructure

WEB Products Vs. Packaged Products

• WEB products are WEB services!–Requires maintenance for a better service

• Short life cycle - many releases.

• Different “perspective” to measure quality.

• Different drive and focus on:globalization – localization – process.

Short Lifecycle Vs. Workload

Major releases: usually 3-4x per year

Minor revamps: every 2-4 weeks

Disaster cases: not scheduled security fixesvery short turnaround time (24 hours)

Time

Work

load

Different Point of View on Quality

Packaged Products

Bugs are too costlye.g. re-releases, recalls, etc.

Online Services

More focus on the Content as it is the first element a user will see/experience.

100% 100%

30%

Functionality LocalizationLanguage

100% 70%

30%

Functionality LocalizationLanguage

The first impression is the one that counts!!

A Recipe for a Successful WEB Product

• “True” Globalized code

• Excellent localizability

• Process for quick turnaround

• Process for a vendor outsource model

Globalization

English becomes just another language!

• Web services run on machines with different:OS – locale – browser - time zones – char. set - etc.

• Awareness during development

…and you need to drive these issues!

Globalization

You also need to be aware and drive:

• Vendorization of the product–Developer awareness of localization tools.–Simple & understandable code.

• Focus on markets and their specific issues/needs–Language centric vs. Market centric.

Localization

• New challenges and focus–“Vendor proof” localizability.–Fast turnaround Process.–“Smart” Testing process.

• Use new technology–Find better ways to do the job.

The Process – the “Old” ModelMicrosoft Example

US

MSIreland MSBPN

Vendorhub

Sub hub/vendor

Sub hub/vendor

Sub hub/vendor

Corporate netw ork

Internet

The Process – the “New” Model

MS Redmond

EN (R)

FR (RW)

DE (RW)

File structure

InternetMS Ireland

MS business partners

FTP

HTTP

Test server

MS Redmond

MS Ireland

MS Business Partners

INTERNET

Virtual team

• File transfer

• Localization

• Testing

• Engineering

• IQA review

• Sub review

I n ternet

TEST SERVER

VEN HUB

LANG VEN

RED W E

IRL W E

IQA

SUBS

Virtual teamINTERNET

Contingency Planning

• How do you prepare for unplanned change?• What can you do when a host or deliverables

dates change?• What’s the right amount of buffer to build into

your work?• How can you find out early that change is

coming?• A new project arrives on an already stretched

team

Beyond CC: Bugs, Bugs Bugs.• No change in code without a bug.• Each fix has benefits/costs. Know the trade-off.• Fix/Punt the ‘right’ bugs.• Use stabilization milestones: BETAs, ZBRs,

weekly goals.• Understand the active/resolved/regress trends.

This is your schedule.• Triage regularly, start early but not too early.

Agent for Change

• PM is an Agent for change

• Escalate-Escalate-Escalate

• Build a network - IPM’s, Loc teams, Key influencers

• Cheaper - an argument with weight

• Faster - ‘delight’ the customer

• Set loc requirements - first milestone for every project

Things to avoid

• Making assumptions

• What worked before will work again

• That it’s easy so does not need a formal procedure

• Relying on good will and co-operation of others

• Someone else won’t do it