Internationalization Basics Webinar Slides
•0 likes•293 views
Report
Share
Download to read offline
These slides review the basics of internationalizing software to prepare it for global markets and cover the issues, common mistakes, organizational solutions and ROI.
Recommended
More Related Content
Viewers also liked
Viewers also liked(19)
Similar to Internationalization Basics Webinar Slides
Similar to Internationalization Basics Webinar Slides(20)
Recently uploaded
Recently uploaded(20)
Internationalization Basics Webinar Slides
- 2. Agenda • Intro to Lingoport • Basic terminology and i18n concepts • Top 10 i18n issues • Continuous Globalization o Software Globalization & Development Cycles o Integrating i18n & L10n with sprints • ROI • Q&A, Follow-up Resources
- 4. Lingoport Suite Painless support & actionable data to facilitate ongoing software internationalization and localization.
- 5. i18n (i + nternationalizatio + n) o the process of making code world-ready so that it can be localized to a specific region and language L10n (L + ocalizatio + n) o the process of adapting the application content to meet the language, cultural and other requirements of a specific target market G11n (g + lobalizatio + n) o the process of designing and developing a software product that functions in multiple countries and languages i18n, L10n, g11n 5
- 6. g11n = i18n + L10n 6
- 7. I18n Issues Overview What’s not in the code (architecture and design) • Locale • Assumptions about use and interaction • Flexibility for regulations or market requirements • 3rd party product dependencies What’s in the code • Embedded Strings o Concatenations • Locale-Unsafe Methods, Functions, Classes • Programming Patterns • Static File References
- 8. Top 10 i18n Issues ©Lingoport, Inc. 2013 - do not distribute 8
- 9. #1 – Character Corruption Some characters show up corrupted 文字化け: (mojibake) "character change" ©Lingoport, Inc. 2013 - do not distribute 9
- 10. #2 – Hard-Coded or Embedded Strings Embedded strings are hard-coded character strings in the source code. In the example below, some text stays in U.S. English regardless of the user language ©Lingoport, Inc. 2013 - do not distribute 10
- 11. #3: Incorrect Date / Time Format The date or the time shows up with a U.S. English format; here the date is shown as May 6th, 2011 ©Lingoport, Inc. 2013 - do not distribute 11
- 12. #4: Programming Shortcuts Developers can take shortcuts in a U.S. English application that do not transfer to an international audience Here the table names are used to display a selection ©Lingoport, Inc. 2013 - do not distribute 12
- 13. #5: Designing without Considering i18n Designing software without thinking about international markets can lead to re-writes later on Here, an on-screen keyboard only lets the user type in ASCII characters. ©Lingoport, Inc. 2013 - do not distribute 13
- 14. #6: Emails If the application sends email, that part of the software must be examined carefully Here there is a mix of Japanese and U.S. English text ©Lingoport, Inc. 2013 - do not distribute 14
- 15. #7: Parsing and Displaying Numbers The application fails to parse a number because it was entered with a comma decimal separator, as in the French “12,50” as opposed to the U.S. “12.50” ©Lingoport, Inc. 2013 - do not distribute 15
- 16. #8: Static File References Showing or playing a file in the wrong language o Html Files o Videos o Images ©Lingoport, Inc. 2013 - do not distribute 16
- 17. #9: Currencies Currencies need special attention Here, the currency symbol is wrong, which makes the result unusable ©Lingoport, Inc. 2013 - do not distribute 17
- 18. #10: Understanding Usage Models In the following link, an honest view as to why the initial QuickBooks introduction to Japan did not go well o http://www.inc.com/chris-beier-and-daniel-wolfman/intuit-quicken- scott-cook-global-expansion-failed.html ©Lingoport, Inc. 2013 - do not distribute 18
- 19. Doesn’t Java Support i18n? Written in Java (or others) does not mean internationalized Here the software does not properly validate entries static boolean checkString(String argument) { for (int i=0; i<argument.length(); i++) { char a = argument.charAt(i); if ((a >= ‘A’ && a <= ‘Z’) || (a >= ‘A’ && a <= ‘Z’)) continue; else return false; ©Lingoport, Inc. 2013 - do not distribute 19
- 20. Tackling i18n Projects Determine the i18n requirements Assess the situation o Architectural view o Code specifics Come up with a plan, a budget, a time line o Is the plan approved by management? o Rarely ‘easy’ or ‘cheap’ o Build it into each feature Execute on the software development, QA, Linguistics plan ©Lingoport, Inc. 2013 - do not distribute 20
- 21. Agile Development Continuous Globalization (G11n)
- 22. Defect costs per stage Traditional approach to SW Development in a well defined process When most i18n & L10n issues are addressed
- 23. G11n & Agile i18n & L10n issues often Fall into backlogs
- 24. Continuous G11n
- 25. I18n in Software Development i18n compliance through iterative QA cycles and releases is a waste of money and time Finding, managing, fixing and verifying i18n bugs is costly. Averages start at $500/bug. Interrupts the flow of development Releasing core products to worldwide markets faster creates revenue opportunities, not just cost savings “Reactive internationalization is unpredictable and poorly controlled.” – Gary Lefman, Cisco i18n Architect. ©Lingoport, Inc. 2013 - do not distribute 25
- 26. • 5 Teams X 20 sprints/year = 100 Sprints • Each sprint has 5 features = 500 features • 2 days saved per feature = 1,000 days • At $40/hour = $325,000 per year • Productivity increase of 3 people per year Continuous G11n ROI
- 27. Questions & Answers: Contact Resources Adam Asnes CEO & President Lingoport, Inc. http://www.lingoport.com Lingoport Suite i18n e-learning i18n consulting • http://lingoport.com/blog • http://lingoport.com/resources • http://lingoport.com/products
Editor's Notes
- Globalyzer: Find and fix internationalization (i18n) issues that inhibit localization and global user experience during development. Catch up on i18n technical debt. Dashboard: The hub of our suite. See it all, drill down, create notifications and manage the process. Bridge gaps between localization & development. Increase visibility and track globalization metrics. LRM: Make localization proactive. Detect & manage changes to resource files in your source code. Streamline translation jobs. Automate localization updates between development and translation.
- Internationalization, commonly called i18n for short, is the process of making software code generic, or world-ready, so that it can be cost-effectively localized to a specific region or language. i18n is a software development task. It is not translation; it is a prerequisite for translation. Localization is the process of adapting an application and related content to meet the linguistic and cultural requirements of a specific target market. One aspect of Localization is the translation of text into target languages, such as French, but this is not necessarily all. Globalization is the process of designing and developing a software product that functions in multiple countries and languages. You may hear the term NLS, or National Language Support, used for instance for Oracle products when describing internationalization APIs. The focus for this session is internationalization. The primary target audience is software developers.
- In general, the standard process for creating, globalized, world-ready software starts with internationalization, which includes software development techniques and best practices. This supports localization, which involves translation and customizing a product for a specific market after the software has been internationalized. Once fully internationalized, an application may be localized for many countries and languages without changes to the code.
- In this screenshot, the text entered by a user contains accented German characters. The application somehow mangles those accented characters and displays them as diamonds with question marks in the User Interface. Similar issues could arise with East Asian, Cyrillic, Arabic, or Korean characters. This type of corruption can render an application unusable for certain markets. In fact, there is a special word for this in Japanese: “mojibake.”
- Sometimes developers leave character strings embedded, or “hard-coded” in the source code. In this example, an English string appears in an application running in German. Whatever the user language, these hard-coded strings will remain in English. Hard-coded strings can be show-stoppers that prevent the release of an application to international markets, or the software may be rejected by the users.
- In this application, a date object is displayed to the German user as if she were a U.S. English speaker: May 6, 2011. Incorrect date and time formatting are notorious i18n issues.
- Software developers sometimes take shortcuts when developing a non-internationalized application; those short-cuts can later lead to i18n issues. In this case, the application displays the database column names to make the SQL statement easier for the developer. In this example, the application displays checkbox labels using column names retrieved directly from a database. This means that regardless which language the user prefers, the checkbox labels will remain the same. This code will need to be reworked so that the labels can be displayed in the user’s language.
- Designing software without thinking about international markets can lead to re-writes later on. In this example, the user can only interact with the application using an on-screen keyboard and the only keys available are ASCII. It is impossible for a Chinese user to enter text in her language or for a French user to enter accented characters. In other words, this application cannot work outside of an English speaking market. The i18n work will have to include replacing the on-screen keyboard.
- Emails must be carefully examined and may be unusable for international markets. Some email systems may use templates that support different languages, yet the application fails in setting the language for a recipient based on his or her profile. Sometimes, there is a mix of data in two or more languages. In this example, some of the email text is in U.S. English and some is in Japanese, which makes it difficult for both audiences.
- Numbers must be entered and displayed according to the user’s language and country. One issue is with the decimal separator, which can be a comma or a period depending on the country. In this example, the application fails to parse a number with a comma as the decimal separator. The French user entered “12-comma-50” and the application cannot continue.
- Applications can show html files or videos or images or even play audio files. Those files are static. They don’t do anything from a software perspective; they are simply shown or played. In this slide, the application shows a Japanese license agreement, which may not be helpful for an English speaking user. Another example is an audio file warning of a specific problem. If the audio file is played in Japanese, a U.S. user may not understand it. Choosing the wrong static file is a common i18n mistake.
- Currencies need special attention. Many problems can arise in this sensitive area. For instance, the wrong currency symbol may be used. In this example, the $ (dollar) sign is mixed up with the Japanese Yen currency symbol. The result is unusable. The format of the number could also be incorrect, leading to differences of thousands of dollars. Also, an amount displayed in Euro may first be recalculated based on an exchange rate; if it is not, the amount is wrong. Currencies are sensitive problems.
- Sometimes, more research into a country business habits is necessary. In this video, Scott Cook, CEO of Intuit, explains frankly why the Japanese version of QuickBooks was poorly received. The usage model of taxation in Japan is different from an accounting perspective; And the way the user’s work need to flow from one task to another is also different. Understanding usage models in different countries may have a strong impact on the overall software product design and acceptance.
- Some people may erroneously believe that programming in certain languages automatically implies internationalization. It does not. Java and .NET, for instance, include extensive support for i18n. Yet, having an application written in Java or .NET does not necessarily mean it is internationalized. In this short snippet of Java code, a name is correct if all the letters in the name are between ‘a’ and ‘z’. Entering the French accented character “é” fails.
- The best approach to internationalization begins with realizing that internationalization is part of software engineering and has a set of best practices and techniques. To start, make sure you know the requirements. These could include but not be limited to: the target countries; the desired languages; and the impacted areas of code. One must also know what is not impacted, for example: the installation script for a web site may be out-of-scope. Then assess the situation. Use products like Lingoport’s Globalyzer to check the code for possible i18n issues. An architectural understanding of the application is also typically needed for a proper i18n assessment. Assessments should lead to planning i18n projects organized by individual software tasks, followed by budgeting the effort. When the plan is approved, the i18n project can be staged like most software projects, from design to implementation to QA, with special attention to how L10n deliverables can be folded back into the application or how to best carry out specific i18n QA and linguistic testing.
- Some people will be focused on L10n some on i18n. Both are important! The logical flow is to make sure i18n is in line to support L10n Translation can be very integrated: i.e. client who integrates with WorldServer Can also integrate with your L10n Vendor’s portals, other translation systems like LingoTEK Back in to build with file quality checks. Gives you more time for staging QA.
- Implementing i18n as an afterthought, as opposed to addressing i18n upstream in the development cycle, typically leads to many iterative QA cycles that find defects needing correction by development. This leads to high costs and late delivery to markets, hence decreased or – in the best case - delayed revenues for the company. Some industry average numbers place the cost of i18n bug fixing to about $500, including finding the bug and logging it, managing the bug, fixing it in development, moving it back to QA, and finally verifying and closing it. Gary Lefman, a Cisco i18n specialist, summarizes this situation by stating that “Reactive internationalization is unpredictable and poorly controlled.” When trying to address more and more world-wide markets to increase revenues, organizations must optimize their processes by taking advantage of i18n products.