Challenges of Web Localization: Scaling Up the Work and Improving the Localization

Process (A Case Study)

Eva KlaudinyovaManager, Localization

VMware Inc.

Agenda

1. VMware at a glance2. Web localization at VMware3. Tsunami called vSphere4. Saving grace: Planning, planning, planning5. Execution: Dealing with the flood6. Lessons from survivors7. Where do we go from here?

VMware at a glance

VMware (NYSE: VMW) is the global leader in virtualization solutions from the desktop to the datacenter—bringing cloud computing to businesses of all sizes. Customers rely on VMware to reduce capital and operating expenses, ensure business continuity, strengthen security and go green.

Founded: 1998; acquired by EMC in 2004; IPO in August 20072008 Revenue: $1.9 billionCustomers: 150,000, including 100% of Fortune 100Employees: 7,000+Headquarters: Palo Alto, CA, USALocations: 40+ worldwidePartnerships: More than 22,000

Web localization at VMware

High-level planning and approvals: Weekly management meeting (Web, Glob. Program)Program Management: 2 coordinators, 1 for each teamExecution: Local PMs (LATAM, EMEA, APAC), vendors, internal L10N reviewers

Tsunami called vSphereProject factsEN Web content launched 4/21International Web content launched 6/29

•DE, JP and CN (major updates), plus minor updates in 7 other languages • 9 sections and 400+ URLs updated•9,700 xml files processed per language, total of 450K words translated in 3 languages (50.7% new words)•16 Glob. Team members and 8 Web team members involved •1500 internal man hours spent on localization (program and project management, translation, 2 rounds of review)•1,000 on Web production and QA (planning and scoping, coordination, web dev support, graphics localization, video subtitling, Web production and QA )•Localization timeline: Apr 14-Jun 10 (8 weeks) + 2 more weeks to finish online reviews

Tsunami called vSphere (cont.)Project challenges:1.Clunky CMS

• Exporting dozens of xml files per page• Re-exporting same files for all pages (e.g. top nav, right-hand nav)• Using lots of code requiring special filter for file processing• New code popping up during the life of project

2.New TMS• Only implemented couple of months before project start• Still in learning curve• Could not process xml files from TMS without custom-built filter (3 filter updates during

project)• Took several hours to process 1 zip file (~65 zip files x 3 languages)

3.Extremely tight deadline• 8 weeks for localization including review in TMS• 1.5 additional weeks to finish online reviews of staged content on production server• Online review feedback had to be implemented directly into the pages using CMS

4.Content updates during project and scope creep5.Resource issues6.Budget constraints

Saving grace: Planning, planning, planning…

Our saving grace - advance notice of 2 months, which we used for:

PPPT = Process, People, Plan, Tools

1. Process development, identifying roles and responsibilities2. Information sharing (document mgmt portal)3. Resource building (added reviewers in 10 languages)4. Project plan, schedule, scope management (batching)5. Plan B and C (vendor tool and filter; our tool but for pre- and post-processing only)6. TMS training7. Customized filter development and testing8. Pilot projects

Execution: Dealing with the floodProcess

Execution: Dealing with the flood (cont.)

Execution: Dealing with the flood (cont.)Schedules

Lessons from survivors

1. Establish relationships2. Develop process3. Define expectations4. Clarify roles and responsibilities5. Communicate constantly (internally, with stakeholders, with vendors)6. Plan in advance, create schedule7. Have Plan B8. Be flexible and prepared for emergencies9. Automate and use tools10. Test (tools, process)

Where do we go from here?

Internally: 1. New CMS

Adapt process Adapt TMS (workflow and filter)

2. Better high-level planning (defining product launch expectations)

3. Consistent adherence to process

Cross-functionally:4. Transparent resource scheduling

5 . Stakeholder education

Q & A