10 Commandments Building Global Software
•Download as PPTX, PDF•
1 like•970 views
The document outlines 10 rules for building global software: 1) Maintain user-visible strings separately from code; 2) Expect strings to vary in length across languages; 3) Provide context for translators; 4) Avoid embedding text in images; 5) Account for differences in date/time formats and calendars; 6) Store and display times using UTC and local time zones; 7) Use established data standards; 8) Use Unicode instead of ASCII; 9) Assume text may flow right-to-left; and 10) Test for multilingual support from the start. Following these rules makes software easier to internationalize and localize for global markets.
Recommended
Recommended
More Related Content
Similar to 10 Commandments Building Global Software
Similar to 10 Commandments Building Global Software (20)
Recently uploaded
Recently uploaded (20)
10 Commandments Building Global Software
- 1. The 10 Commandments of Building Global Software #speaksmartling Andrey Akselrod CTO and Co-Founder Smartling Brian Kelly VP, Engineering TimeTrade
- 2. Andrey @chelya Brian @brikelly #speaksmartling Presenters A quick word
- 3. The Global Challenge & …but make it easy to take it to a global market later? #speaksmartling Is it possible to write software for a single region first…
- 4. Global-Ready Software Conventional wisdom Internationalization is hard. Reality It isn’t really that difficult, if you consider some important things during design and development. & #speaksmartling
- 5. Carefully Manage User-Visible Strings #speaksmartling Rule #1
- 6. Carefully Manage User-Visible Strings Global Software Development Rule #1 Maintain user-visible strings separate from application code This makes it easier to send strings to translators and incorporate their work String values must be changeable without breaking application behavior #speaksmartling
- 7. Carefully Manage User-Visible Strings Global Software Development Rule #1 Favor existing platform tools rather than inventing your own #speaksmartling For example: ResourceBundles for Java .resx resources for .NET gettext for C NSLocalizedString for Objective-C
- 8. Carefully Manage User-Visible Strings Global Software Development Rule #1 Concatenation is a recipe for i18n pain Bad: user + “has logged on” Good: “{0} has logged on”
- 9. Carefully Manage User-Visible Strings Global Software Development Rule #1 Include punctuation in your localizable strings Helps prevent breakages on other locales Even more valuable if text flows right-to-left “Don’t forget your spaces!” in French is ”N’oubliez pas vos espaces !” UI sorting order should be based on translated strings Example: “Korea” in Spanish is “Corea”
- 10. Rule #2 Expect User-Visible Strings #speaksmartling to Grow/Shrink
- 11. Expect User-Visible Strings to Grow/Shrink Global Software Development Rule #2 English phrases may double in size when translated into other languages “Read more” is “Weitere informationen” in German They may also drastically shrink when translated into other languages “To fall in love at first sight” is “一见钟情” in Chinese UIs will have to adapt accordingly to accommodate different string lengths
- 12. Remember the Importance of Context #speaksmartling Rule #3
- 13. Remember the Importance of Context Global Software Development Rule #3 #speaksmartling Context is everything for the translator The source string might not be enough Make as much information as possible available to them: UI screenshots, documentation, personas, etc. Or best of all, access to the product itself
- 14. #speaksmartling
- 15. Keep Images Free of Embedded Text #speaksmartling Rule #4
- 16. Keep Images Free of Embedded Text Global Software Development Rule #4 For anything except a company or product logo, avoid creating graphics that have text embedded directly #speaksmartling Instead of a low-cost string translation, you’ll incur graphic design costs if you embed text in graphics
- 17. Consider Calendar Differences #speaksmartling Rule #5
- 18. Consider Calendar Differences Global Software Development Rule #5 Time formats differ from country to country 2:30p.m. 14:30 2:30PM Date formats vary tremendously dd/mm/yyyy mm-dd-yyyy YYYYMMDD Don’t rely on abbreviations to denote days, such as M T W T F S S “M” works for German (“Montag”), but not for Spanish (“lunes”) or Japanese (“月曜日”) #speaksmartling
- 19. Consider Calendar Differences Global Software Development Rule #5 Not everyone in the world has a weekend on Saturday and Sunday #speaksmartling Not all weeks start on Sunday Not all countries use the Gregorian calendar
- 20. Plan for Different Time Zones #speaksmartling Rule #6
- 21. Plan for Different Time Zones Global Software Development Rule #6 There are hundreds of different time zones And they’ve changed a lot through history Even in recent history! Some zones have partial-hour offsets Newfoundland, Nepal #speaksmartling
- 22. Plan for Different Time Zones Global Software Development Rule #6 Always, always store times in UTC And convert to the user’s local time zone when they need to be rendered #speaksmartling Don’t reinvent the wheel Use things like Joda (now included in Java 8 as java.time), Noda, NSDate, and Moment.js to make time, date, and time zone handling easy
- 23. Use Established Data Standards #speaksmartling Rule #7
- 24. Use Established Data Standards Global Software Development Rule #7 #speaksmartling Stand on the shoulders of giants Always use established, globally-focused standards when parsing and storing data
- 25. Use Established Data Standards Global Software Development Rule #7 #speaksmartling International phone numbers? Use E.164 Example: +16175551234 Timestamps? Use ISO-8601 Example: 2014-11-05T13:15:30Z
- 26. Use Established Data Standards Global Software Development Rule #7 #speaksmartling Language codes? Use ISO-639 Example: “zh” for Chinese Country codes? Use ISO-3166 Example: “GB” for the United Kingdom Time zones? Use the Olson database Example: “America/New York” for Eastern Time
- 27. Avoid ASCII, Use Unicode #speaksmartling Rule #8
- 28. #speaksmartling Avoid ASCII, Use Unicode Global Software Development Rule #8 The days of the ASCII bit-flip trick are gone “a” = 01100001 “A” = 01000001 Unicode is here to stay And has been around for years already
- 29. #speaksmartling Avoid ASCII, Use Unicode Global Software Development Rule #8 To use Unicode properly, you must use it consistently throughout your application Always use Unicode-capable types and libraries Never assume that characters are encoded in ASCII Need to choose an encoding? Use UTF-8
- 30. Avoid ASCII, Use Unicode Global Software Development Rule #8 Strings in databases should be given extra scrutiny Never assume that one character equals one byte – especially important for column sizing Use Unicode-compatible DB types for user-visible strings utf8mb4 for MySQL, nvarchar for SQL Server #speaksmartling
- 31. Rule #9 Assume Text May Flow from Right to Left #speaksmartling
- 32. Assume Text May Flow from Right to Left Global Software Development Rule #9 Arabic, Hebrew, Persian, Urdu (and more) all flow from right to left But what if left-to-right content is quoted within? And what about embedded numerals? #speaksmartling
- 33. Assume Text May Flow from Right to Left #globalsoftware Global Software Development Rule #9 When building a web application, regularly test how it displays when you apply this CSS3 property globally: direction: rtl; Use R2 (or similar) to flip css: https://github.com/ded/R2
- 34. Rule #10 Test from Day One for Multilingual Support #speaksmartling
- 35. Test from Day One for Multilingual Support #speaksmartling Global Software Development Rule #10 “Pseudo-internationalization” is one of the most valuable future-proofing tests you can add to your automated suite If you ever plan to bring your application to global markets, testing with pseudo-i18n will identify architectural issues early
- 36. Test from Day One for Multilingual Support #speaksmartling Global Software Development Rule #10 Instead of using test data like “John Doe”, use “John- 假会河Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- 37. Test from Day One for Multilingual Support Global Software Development Rule #10 Web Browser Web Server App Server DB “John-假会河 Doe-沖鈈批” “John-假会河 Doe-沖鈈批” “John-假会河 Doe-沖鈈批” “John-?????? Doe-??????” “John-?????? Doe-??????” “John-假会河 Doe-沖鈈批” Example of Pseudo-i18n #speaksmartling
- 38. Questions, anyone? We’ll be glad to answer. #speaksmartling
- 39. Want a copy of our slides? hi@smartling.com #speaksmartling
- 40. Want to learn more about the software we’ve built for the world? smartling.com timetrade.com #speaksmartling
Editor's Notes
- For example: ResourceBundles for Java .resx resources for .NET gettext for C NSLocalizedString for Objective-C
- Concatenation is a recipe for i18n pain Bad: user + “ has logged on” Good: “{0} has logged on”
- English phrases may double in size when translated to other languages “Red more” is “Weitere Informationen” in German They may drastically shrink when translated into other languages “To fall in love at first sight” is “一见钟情” in Chinese UIs will have to adapt accordingly to accommodate different string lengths
- There are hundreds of different time zones And they’ve changed a lot through history Even in recent history! Some zones have partial-hour offsets Newfoundland, Nepal
- Always, always store times in UTC And convert to the user’s local time zone when they need to be rendered Don’t reinvent the wheel Use things like Joda (now included in Java 8 as java.time), Noda, NSDate, and Moment.js to make time, date, and time zone handling easy
- Always use established, globally-focused standards when parsing and storing data
- International phone numbers? Use E.164 Example: +16175551234 Timestamps? Use ISO-8601 Example: 2014-11-05T13:15:30Z
- Language codes? Use ISO-639 Example: “zh” for Chinese Country codes? Use ISO-3166 Example: “GB” for the United Kingdom Time zones? Use the Olson database Example: “America/New_York” for Eastern Time
- The days of the ASCII bit-flip trick are long gone… “a” = 01100001 “A” = 01000001 Unicode is here to stay – and has been around for years already
- To use Unicode properly, you must use it consistently throughout your application Always use Unicode-capable types and libraries Never assume that characters are encoded in ASCII Need to choose an encoding? Use UTF-8
- Strings in databases should be given extra scrutiny Never assume that that one character equals one byte - especially important for column sizing Use Unicode-compatible DB types for user-visible strings utf8mb4 for MySQL, nvarchar for SQL Server
- Arabic, Hebrew, Persian, and Urdu (and more) all flow from right-to-left But what if left-to-right content is quoted within? And what about embedded numerals?
- When building a web application, regularly test how it displays when you apply this CSS3 property globally: direction: rtl; Use R2 (or similar) to flip css: https://github.com/ded/R2
- “Pseudo-internationalization” is one of the most valuable future-proofing tests you could add to your automated suite If you ever plan to bring your application to global markets, testing with pseudo-i18n will identify architectural issues early
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual
- Instead of using test data like “John Doe”, use “John-假会河 Doe-沖鈈批” instead Doing so will verify that all APIs, libraries, databases, and code within your application can parse and store Unicode You don’t have to localize your application to test it for basic i18n effectiveness, and your team doesn’t have to be bilingual