Globalization Maturity Analysis for New Acquisitions

1. G11n/L10N Maturity Analysis for New Acquisitions Author: Louis Huang, Lilian Lai, Fei Shen, Peter DC Wang

2. Agenda • Background • White Box Assessment • Analyzing code and assessing its level of globalization enablement • Black Box Assessment • Testing software for globalization enablement • G11n Consistency and Integration • Inconsistency of globalization level between different components and 3rd party components. • Conclusion

3. Background • Software development becomes more and more complex • Difficult to assess the globalization quality and development/test cost, so here we will introduce our approaches and best practices: • White Box Assessment • Black Box Assessment • Modern globalization should consider emerging technology, way of development, and the integration of different components and 3rd party components. • We should know the globalization maturity of a product before really going into globalization enablement, so the maturity analysis is important.

4. White Box Assessment • Current problems • Many globalization coding errors are difficult to find during team code reviews • Developers lack globalization programming experience. • Globalization problems are often not discovered until late in the testing cycle causing expensive rework. • Globalization code analysis • The globalization code analysis are a set of coding rules that can be used to identify and eliminate globalization coding errors early in thedevelopment phase.

5. White Box Assessment Globalization Best Practices Globalization coding guideline, Templates, APIs, Patterns, ... ... G11n Analysis Rules code patterns Java, C, C++, JSP, ... Analysis Tool 5

6. Perform Analysis GenerateResult White Box Assessment – categories for code analysis • 6 categories and 47 rules for g11n analysis • Culture formatting (16) • Encoding (9) • Locale Handling (2) • String Handling (14) • Translation (2) • UI Specific (4 Static Analysis Tool SourceCode AnalysisReport GlobalizationRules J2EERules SecurityRules GlobalizationRules NamingRules J2EERules

7. White Box Assessment – culture formatting check

8. White Box Assessment – encoding check

9. White Box Assessment – locale handling check

10. White Box Assessment – string handling check

11. White Box Assessment – translation check

12. White Box Assessment – translation check

13. White Box Assessment – UI specific check

14. Black Box Assessment • Globalization check list • Cultural selectability • Language support • Multilingual support • Linguistic technologies • Country or region support • Translatability

15. Black Box Assessment - Globalization check list

16. Black Box Assessment - Globalization check list

17. G11n Consistency and Integration • BackgroundEach component uses different web framework and each framework handles the language and locale preferences differently. • Consistency issues • Translation level difference • Number of translated languages • Locale recognition difference • Some honor xx_xx but not xx or xxx • Fallback mechanism difference • Client preference language fallback (1st languages, 2nd language, …) • Server locale preference fallback (server deployed locale) • Cultural level difference • Some use ICU but some use Java or others • Others

18. G11n Consistency and Integration • Given a browser preference languages order as, zh, en-us and tr • Due to different fallback models, it causes mixed translation UI panels Chinese UI – shows zh resources correctly English UI – only recognizes 4 characters identifiers Turkish UI – loads the first available language resource

19. G11n Consistency and Integration - suggestions • Default UI language should be configurable by system admin at multiple levels - per application / per host. • Better to set default UI language to English if no language configuration above is available • We can have language UI and cultural format setting separately (ideally), if not, we can provide best available match strategy. By default, use the best available match strategy - for example, English UI + Chinese Culture support (1st languages, 2nd language, …) • Forcomposite application which integrates heterogeneous components better provide common user preferences including preferred UI language / cultural formatting • To provide consistent behavior across sub-components, composite app container should provide a common globalization preference support framework

20. G11n Consistency and Integration G11N Differences Collection Globalization Preferences Definition Reach Common Preferences User Specific Configurations Component A Globalization Preferences / Objects Heterogeneous Components Algorithm to decide proper G11N elements to collect them in single G11N services or objects • Proper Locale • Proper UI Language • Proper Fallback Mechanism • Proper Cultural Formats Component B Server G11N Configurations Component N Corporate Requirements

21. Conclusion • With white box and black box assessment result, users can come out reference data for managers and developer to do cost estimate • Globalization problems can be discovered early in the testing cycle without rework. • It can save translation cost with better translation quality • With good globalization quality to the local language or languages where the customer does business, the product can bring more satisfaction and revenue.