28
From Lingoport: Adam Asnes Michael Asnes June 22, 2016

Continuous Globalization Workflow Webinar Slides

Embed Size (px)

Citation preview

From Lingoport:Adam AsnesMichael AsnesJune 22, 2016

• Background info and mindset

• Continuous globalization concepts

• Agile

• Continuous systems

• Static analysis

• Lingoport Suite

• Workflow diagrams

• Workflow Demo

• Q&A

• Internationalization – i18n

• Localization – L10n

• Globalization – G11n

• My name: A2m

• 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

• 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.

• Potentially Purgatory for G11n issues

• Putting bugs here kills forward momentumo Need to document, recreate, find in the code, fix and verify

• Further complicationso Code reuse

o Acquisitions and legacy code issuesi18n & L10n issues oftenFall into backlogs

Traditional approach to SW Development in a well defined process- Capers Jones

When most i18n & L10n issues are addressed

Use static AnalysisFor i18n & L10n

• Static Analysis o on current work and source repository

• QA and automationo Functional testing, via automated Pseudo-localization

• Automated L10n workflowo Detecting L10n changes to files, verifying, sending for translation, verifying, importing

back to the repo

• Dashboardso Visibility

o Metrics over time

o Drill down

• Measuring conditions in source code, rather than having to actively test

• Code scanning, looking for specific conditions:o Bugso Securityo i18no L10n Changes to the resource files in the code

repository(s)

• Do both!

• Testing requires that you hit all conditions to be measured

• Testing is by its nature an iterative loopo Code, test, fix, verify

o Can take more time, more to manage, more manual processes

o More human error or omission

• 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 potentialso Coding

o Requirements

o Design

• Achieving Software Excellence, 2016

• Exceeding 99% in Defect Removal Efficiency (DRE) for Software, 2016

o Capers Jones

Systems, automation & measurement to facilitate ongoing software internationalization

and localization.

• G11n visibility over multiple products and projects

• Drill down & Planning

• 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

• See what’s new in resource bundles

• Automate Prep Kits

• Automate file validation

• Automate sending files for Localizationo 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

i18n & L10n in Every Sprint and Release

• Automation

• Visibility

•Metrics

• 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

Contact Resources• lingoport.com/blog

• lingoport.com/resources

• wiki.lingoport.com

Adam Asnes

[email protected]

Michael Asnes

[email protected]

http://www.lingoport.com

Lingoport Suite

Extensive Services

Training – training.lingoport.com

• 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?

• 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.

• 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?