The document discusses continuous globalization and localization workflows. It describes Lingoport's suite of tools which provide continuous measurement, automation and visibility for internationalization and localization. The tools accommodate continuous change, measure localization issues, and integrate localization into every sprint and release. Lingoport representatives were available to answer questions.

1. From Lingoport:
Adam Asnes
Michael Asnes
June 22, 2016

2. • Background info and mindset
• Continuous globalization concepts
• Agile
• Continuous systems
• Static analysis
• Lingoport Suite
• Workflow diagrams
• Workflow Demo
• Q&A

3. • Internationalization – i18n
• Localization – L10n
• Globalization – G11n
• My name: A2m

5. • Continuous measurement for i18n & L10n
• Within the natural path of development
• Automated
• Visible
• Actionable:
o Tracking detailed to the line of code
• Forgiving: Multiple options for dealing with false
positives

7. • Accommodate continuous change throughout the
development cycle
• Stresses rapid delivery of working software, empowerment of
developers, collaboration between developers and rest of
team, including business people.
• Waterfall is front end loaded with comprehensive scope and
requirements, clear handoffs.
• Agile incorporates a continuous stream of requirements
gathering.

8. • Potentially Purgatory for G11n issues
• Putting bugs here kills forward momentum
o Need to document, recreate, find in the code, fix and verify
• Further complications
o Code reuse
o Acquisitions and legacy code issues
i18n & L10n issues often
Fall into backlogs

9. Traditional approach to SW Development in a well defined process
- Capers Jones
When most i18n & L10n
issues are addressed
Use static Analysis
For i18n & L10n

10. • Static Analysis
o on current work and source repository
• QA and automation
o Functional testing, via automated Pseudo-localization
• Automated L10n workflow
o Detecting L10n changes to files, verifying, sending for translation, verifying, importing
back to the repo
• Dashboards
o Visibility
o Metrics over time
o Drill down

11. • Measuring conditions in source code,
rather than having to actively test
• Code scanning, looking for specific
conditions:
o Bugs
o Security
o i18n
o L10n Changes to the resource files in the code
repository(s)

13. • Do both!
• Testing requires that you hit all conditions to be
measured
• Testing is by its nature an iterative loop
o Code, test, fix, verify
o Can take more time, more to manage, more manual processes
o More human error or omission

14. • High quality using a synergistic combination of defect prevention,
pre-test inspections and static analysis combined with formal
testing is fast and cheap.
• Poor quality is expensive, slow, and unfortunately far too common.
• Teams reporting the most errors tend to have the best quality.
• Leading activities for common defect potentials
o Coding
o Requirements
o Design
• Achieving Software Excellence, 2016
• Exceeding 99% in Defect Removal Efficiency (DRE) for Software, 2016
o Capers Jones

15. Systems, automation & measurement to
facilitate ongoing software internationalization
and localization.

16. • G11n visibility over multiple products and projects
• Drill down & Planning

17. • Server: Customize and store Rules (no source access)
• Workbench: Big i18n jobs, Configure rules, i18n focus
• Lite: i18n check from developer IDE or automated check-in
• Command Line: Automate i18n measurement from the repo

18. • See what’s new in resource bundles
• Automate Prep Kits
• Automate file validation
• Automate sending files for Localization
o Via TMS or L10n Vendor Portal
• Track it
• Validate it when it comes back
• Automatically insert it back in the repo if it passes
• Email notifications as well as dashboard instrumentation
• Automated Pseudo Localization

19. i18n & L10n in Every Sprint and Release

22. • Automation
• Visibility
• Metrics

24. • Your development teams are moving fast
• Global user experience matters and should be
a formal consideration for product
development
• Make i18n & L10n a measured & visible part
of every sprint

25. Contact Resources
• lingoport.com/blog
• lingoport.com/resources
• wiki.lingoport.com
Adam Asnes
aasnes@lingoport.com
Michael Asnes
masnes@lingoport.com
http://www.lingoport.com
Lingoport Suite
Extensive Services
Training – training.lingoport.com

26. • When is the right time and situation to introduce a
pseudolocalization?
• Are there automation-capable pseudolocalization tools I can insert
into my build workflow? Which tools? How to insert?
• How can I select translation cost vs quality tradeoff by target
market and language, and change the choice as my product
matures? e.g. low-cost, low-quality, all MT when I first add a
language, cutting over to high-cost, high-quality human translation
later, without throwing everything away at each change?
• How to integrate with specific build tools like Github or local git for
source code control, Jenkins for build and automated test, Docker
for deployment, Asana or Jira or Mozilla for bug tracking?

27. • My questions are related to all the topics at once – in
summary our biggest issue working at the same time on an
initial translation of an iteration as well as in context review of
the initial round. The scope might even involve the same part
of the text. So what is the best way to keep these two things
apart? Or mix them? Or in general how to deal with that first.
• Also a challenge – always getting shorter timelines and of
course the challenges of getting reliable in context review
methods.

28. • What is continuous globalization?
• What are the steps in a workflow that doesn’t use continuous
globalization and one that does?
• What considerations are important in translating and
localizing user interfaces?