Incorporating l10n into the
Software Development Lifecycle
to create a global Expedia
website
Lindsay Cook, Localisation Program
Manager, Expedia
9 June 2009
Today’s presentation
• Show how Expedia incorporates l10n into the
software development lifecycle in order to
simultaneously ship enhancements globally
• Context:
– Who we are
– How we are organised
– How we work
• Where localisation fits in
• How we are able to simship enhancements globally
• Challenges, pros and cons
Expedia, Inc
North America
Specialty &
Private Label
Corporate
International
Context
• Expedia is part of Expedia, Inc
– 18 sites globally:
• Europe:
– .co.uk, .fr, it, .de, .nl, .es, .be, .ie, .dk, .se, .no, .at
• APAC:
– .com.au, .co.nz, .co.in, .co.jp
• North America:
– .com, .ca
– Each site can be configured differently and
features can be switched on and off
• e.g. display of taxes and fees
Context
• Expedia technology team:
– Large in house development team based in Seattle and
London
– Increasing use of external partners based in Hungary and
China
– Development team made up of Program Managers,
Developers, Testers, Release and IT support
– Organised into global groups with close business
partnership
– Largely split by front end v back end
Context
• Technology:
– Multiple platforms/technologies
• C++, Java, .NET, SQL Databases
• Live site releases:
–
–
–
–
4 planned major releases per year
6-8 planned minor releases per year
Multiple ad hoc deployments
Simship features to all sites
• Development methodologies:
– Mix of waterfall and agile
Expedia User Interface Localisation
• Localisation Program Managers within development
team
– Expedia localisation experts
– Consult, advise, support
– Deep understanding of product, technology, release
process as well as localisation
– Liaise with central localisation team
• Central localisation team in a separate organisation
– Not part of the technology team
– Localisation partner communication and management
– Linguistic Quality
• Multiple external localisation partners
SDLC
Requirements
Specification
and designs
Development
and test
Pre-release
signoffs
• Localisation takes place throughout project development
Requirements
• Requirements are global
• Identified and communicated early in the
process
– This means anything new/large/problematic is
highlighted very early
• Change management process in place for
requirement changes later on in the process
• Requirements form the basis for all
subsequent phases
Specifications and Designs
• Specifications
– Specifications written by Program Managers and reviewed
by all stakeholders
• Localisation is treated as a stakeholder
– Opportunity to feedback potential “localisation issues”
• Implementation of a feature can be changed if not suitable for
localisation
• Designs
– User Interface designs provided by Customer Experience
– Opportunity to feedback potential “localisation issues”
• Design can be changed if not global
Development
• Developers expected to write global,
internationalised and localisable code
– I18n and l10n guidelines to be followed
– Source files picked up and localised multiple times
during development
– If code is not “localisation friendly” it is not too
late to fix it as development is not yet complete
– Linguistic QA can take place during development
and testing…
Test
• Localisation testing is incorporated into
functional testing
– Extensive use of pseudo-localisation before
localisation takes place
– Localised files available throughout testing phase
– Test cases carried out across all sites
– Risk based testing used to prioritise test cases
– Internationalisation and localisation defects
identified and resolved while there is still time to
fix them
Pre-release signoffs/milestones
• Localisation specific milestones that need to
be signed off before going live
– At “Zero Defects” there should be no outstanding
localisation defects
– “Test complete” includes completion of testing on
localised sites and linguistic QA
Case study
• Hotel travel guides
– “Fast Twitch” pages designed to be attractive to
Google, enhanced for Search Engine Optimisation
(SEO)
– 17 sites (not Japanese)
• Japanese site is relatively new so not in scope at time of
this project
– Regular releases and updates
– Simship all enhancements
Case Study – Requirements
•
•
•
•
17 sites must be supported
Pages must be localised
Page URLs must be localised
SEO specific text/terminology will be provided
by SEO experts and must be easily changeable
– Actual text provided by business owner in all
languages
• E.g. meta descriptions, SEO keywords
Case Study – Specifications
• Highlight all text on page that needs to be localised,
e.g.
The following string(s) require
localization:
<POS> > <product> > <product>
Destinations in <selected region>
• Show how variables interact with localisable strings
• Show where SEO specific text will be shown and
therefore not “localised”
• Very helpful reference material for the translators
Case Study – Designs
• Designs take text
expansion into account
– Show wrapping, long
strings etc
• Multiple iterations
offers opportunity for
changes
• Remove all “.com”
specific messaging
Case Study – Development
• Regular pseudo-localisation from the start of development
• Examples of i18n defects reported (by dev, test, PM,
translators) during development:
– Untagged and duplicate messages
– Place names not being returned in local language
• Villes près de London
– Word order issues due to variables
• 4 etoiles Hôtels à Londres
• Fixes:
– Tagging untagged messages
– Ensuring local place names returned
– Improved tagging of messages with large numbers of variables to
improve translatability
Case Study – Test
• Test plan specifically calls out localisation testing:
Localisation Testing
Localisation testing will be performed as part of the
feature functional testing.
Localisation testing will likely attempt to mitigate the
risks of:
Layout issues caused by the translation process
The potential for unexpected English text appearing on
localised POS
The potential for the localisation process to introduce
functional errors to the sites
The potential for NLS for a specific POS being incorrectly
configured on our sites target language
Layout issues caused by the translation process
• Automated test cases check against live site to spot
unexpected changes to localised messages
Case Study – Test
• Test coverage carried out and reported across
all sites
Case Study – localisation
• Project spec delivered as reference material
• Weekly handoffs to localisation partner over 2
months
• 2 linguistic QA cycles
• Localisation complete one week before
development/test complete
• Any defects with localisation impact triaged and
reviewed near the end of the project
• No major localisation defects outstanding at release
The end product
Why this approach works
• Localisation is part of development
– Localisation deeply embedded into development
• Processes
• People
– Localisation not seen as a separate task that is
carried out when development is complete
• Localisation requirements identified up front
– Ability to plan and influence
Why this approach works
• Localisation happens early and often
– Defects and issues are found early and fixed
• The right localisation partner
– Key attributes are:
• Flexibility, can-do attitude
• Happy to work in an environment where files are rarely
final
• Well developed engineering practices
• Automated processes to aid turnaround time
Challenges
• Complexity
– Technology, platforms, releases are all complex
– Finding where a message comes from in order to fix it
takes time and knowledge
– Hard for translators to understand the bigger Expedia
picture
• Geographic distribution
– Time differences...West Coast US, China, Hungary, UK
• Challenging release schedules
– Difficult to fit everything in and maintain quality
expectations (both functional and linguistic)
Challenges
• In house and external partners
– Difficult to ensure education and good practices
are shared throughout the organisation
– High turnover means regular localisation
education needed
• Localisation PMs not all from localisation
background
– They need to be trained up from scratch
Summary
• Having localisation as part of development
works
• The Expedia software development lifecycle is
very challenging but we are still able to
simship enhancements to 18 Expedia sites on
a regular basis
Questions?
• I’m sure you have loads of questions…