One of the challenges of any internationalization effort is precisely locating internationalization issues buried in large amounts of source code and turning that data into an achievable plan. In this session, we’ll work with some open-source code using Globalyzer, a tool to evaluate the code base and categorize internationalization issues. We’ll then look at using this data to build and execute an internationalization plan among developer teams. There will also be an emphasis on maintaining code over its development life cycle so that new internationalization issues don’t begin to crop up and create costly iterative delays during localization. The session will share some of the very same proven and repeatable approaches that Lingoport has used to effectively scale and perform extensive internationalization implementations on large applications in a wide variety of programming languages and technologies.

1. Static Analysis for I18n Adam Asnes President and CEO Lingoport www.lingoport.com P: 303.444.8020 Lingoport, Inc. 3980 Broadway Boulder, Colorado USA 80304 +1 303 444 8020 www.lingoport.com Monday, April 05, 2010

2. Presenters Adam Asnes Lingoport

3. Agenda Business Case Traditional Approach Globalyzer Static Analysis Demonstration ROI: Implications and Examples Questions and Answers

4. Business Case: Nothing gets internationalized or localized just because it would be cool

5. Business Case – why it’s important Survival Global Revenues Key business partners 60% or more of revenues Competitiveness Strategic Growth

6. Business Case Localization Support U/I and data management/presentation Enterprise Customer Support Global enterprise customers need Unicode support DB and presentation must support client needs

7. Is It Internationalized? Developers often underestimate i18n requirements Most don’t know the answer Agile or other feature and release requirements often overrun less formally measured i18n requirements There is a Management Value in being able to confirm global readiness

8. Traditional Approach - repeat, and repeat,and repeat, and repeat

9. Tiers and Technologies Time and effort increase

10. Traditional Approach Tedious Search – “hunt and peck” Simple scripts and pseudo-localization testing is insufficient and iterative by nature IDEs are poor at finding i18n issues and across programming languages Finding issues too late Ugly surprises during localization or worse, after release

11. Testing Coding Architectureand Design Requirements Source: “Software Internationalization Tools and Solutions” - XeroxCatch Bugs Early! 30 x 15 x Maintenance 7 x Localization 4 x Acceptance 2 x Development Phase when an I18N bug is detected

12. Testing vs. Static Analysis Testing only validates what can be easily exercised Hard to cover error messages and all aspects of the interface Expensive and inefficient process Static Analysis Evaluates issues at the source level Covers the entire application Guides development through solutions

13. Static I18n Analysis Frequent i18n analysis speeds the process and Measures how coding practices are in compliance with i18n standards What gets measured improves $$$ value in answering management that the software is global and meets a set of standards

14. Examples of what to look for? Presentation Embedded Strings Concatenation Data Display E.g. Calendar, numerical formatting Processing e.g. String processing logic Character encoding Other Pattern matching for special cases

15. Globalyzer Manage, perform and track internationalization so you’re ready for localization

16. Globalyzer Server and Clients Server Command Line Client

17. Static Analysis Example With Globalyzer 3.2 www.globlayzer.com

18. Detection Embedded Strings Locale-unsafe methods, functions, classes per programming language Locale-unsafe programming patters Filtering Conditional – using regex Dictionary matches for strings Special exceptions Individual issue status

19. Building your own Tools Painful to consider, especially over multiple programming languages How do you search for strings? Research and find methods/functions/classes across programming languages Difficult to gain intelligent results that can be built upon for precise direction during implementation Hard to track issues You now have to support it!

20. Obstacles to Acceptance False Positives – too many issues detected overwhelms developers Globalyzer filtering Globalyzer project files Globalyzer DB tracks issues and exceptions “Auto-magic” solutions usually don’t work in a highly variable environment. Adaptation is a better solution.

22. If we avoided I18N errors, we could save $762K /yr

24. Questions, Contacts & Next Steps Contact: Adam Asnes – adam@lingoport.com