• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Developing for a world wide audience
 

Developing for a world wide audience

on

  • 700 views

 

Statistics

Views

Total Views
700
Views on SlideShare
700
Embed Views
0

Actions

Likes
1
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Public domain image courtesy of Bartledan

Developing for a world wide audience Developing for a world wide audience Presentation Transcript

  • Developing for a World-Wide Audience Michael Labriola Senior Consultant Digital Primates Page 0 of 59
  • Who am I?
    • Michael Labriola
    • Senior Consultant
    • Digital Primates
    • Client side architect specializing in Adobe Flex
      • Designed and implemented UCA and CLDR implementation for ActionScript
      • Lead architect and developer of FlexUnit 4
    • Team Mentor
    • Individual Member of the Unicode Consortium
    • Architected applications deployed worldwide
    Page 2 of 59
  • What are we going to cover?
    • The challenges of internationalizing and localizing an application
    • A general strategy for keeping some of these challenges in check by using a well-defined presentation tier
    Page 3 of 59
  • Terminology
    • As with every technical debate, at some point the definition of the words internationalization(i18n) and localization(L10n) will be called into question.
    • Here are the definitions I choose to use for this presentation:
    Page 4 of 59
  • Terminology
    • i18n – designing and developing a product to be easily adaptable to a multitude of cultures, languages and locations
    • L10n – Adapting that product to meet the needs to a specific market
    Page 5 of 59
  • Challenges of global applications
    • Internationalization is not free.
    • It is usually not cheap.
    • Regardless of the platform you choose for development, it is never completely automatic
    Page 6 of 59
  • Challenges of global applications
    • Internationalization is a process and even more so an awareness that must be continually evaluated throughout development
    • It is made easier when considered from the beginning and disproportionately more difficult when it is an after thought
    Page 7 of 59
  • Challenges of global applications
    • International support is a business decision
    • The goal of internationalizing a product is to reach new markets
    • The ultimate goal is to ensure that the decision to pursue new markets is a business, not a technical, choice
    Page 8 of 59
  • Challenges of global applications
    • The decision to internationalize is a big deal
    • It means a bigger budget, new requirements and longer development and QA cycles
    • Why do it? Ideally to sell the same software the a new marketplace. To achieve a bigger ROI on software.
    Page 9 of 59
  • Challenges of global applications
    • Internationalization is not an all or nothing decision.
    • There are decisions as to the amount of support
    • The more support, the more cost, the more opportunity to reach new markets.
    Page 10 of 59
  • Visibility of Efforts Page 11 of 59
  • Externalizing Content
    • Externalizing content is a highly visible step. It involves removing all hard coded labels and messages
    While visible, only performing this step will mean that you can support different locales speaking the same language reasonably well. You can likely support some additional locales poorly.
  • Challenges: Externalizing
    • Externalizing content means that nothing displayed to the user can be hard-coded in your application
    • Labels
    • User Messages
    • Error Messages
    • Reference Data
    • Date and Time Formats
    • Images
    Page 13 of 59
  • Challenges: Externalizing
    • All external content must be defined in some external source such as a property file, XML document or even database
    • All code must respect variability. You cannot have code such as:
    • if ( selectedItem == "Male" ) {
    • }
    Page 14 of 59
  • Challenges: Externalizing
    • Further, when parsing user input, you cannot assume currency symbols, placement of text punctuation, decimal or thousands separators or order of elements.
    • 1,000.24 or 1.000,24
    • Output display and input parsing need to work together else you are displaying one format to a user and asking them to enter data in another.
    Page 15 of 59
  • Using Unicode
    • Unicode maps every viable character to a unique code point, allowing you access to a multitude of written languages
    CLDR - Unicode Common Locale Data Repository provides locale specific data which explains how to use and format data for a given locale. Page 16 of 59
  • Challenges: Unicode
    • There are various levels of Unicode support in different runtimes, development languages and tools
    • Internally storing strings for display and user input as Unicode code points is a great step forward, however, care still needs to be taken whenever searching, comparing or manipulating strings.
    • Don’t forget where you store the strings
    Page 17 of 59
  • Challenges: Unicode
    • Comparing strings in the world of Unicode is not quite the simple == operation many of us are used to.
    • Standard string comparison functions built into languages may or may not work for this purpose
    • Worse yet, they may appear to work in your locale and only break with others.
    • Does ( a == á ), ( e-mail == email == Email )
    Page 18 of 59
  • Challenges: Unicode
    • By way of example, different operating systems, browser versions and runtimes have different Unicode support.
    • Most versions store strings as UTF-8 or UTF-16 internally, however, support for characters outside of the Basic Multilingual Plane (BMP) is trickier and not as intuitive
    Page 19 of 59
  • Challenges: Unicode
    • Further, remember that there is no such thing as a universal sort
    • Unicode helps us to define common characters. However, those characters are used in different locales in different ways.
    • The same physical character often sorts in a different order in neighboring locales. Ö != Ö
    Page 20 of 59
  • Challenges: Unicode
    • Do not assume that your development tools, language, etc. understands and handles this sorting properly
    • Before version 10.1 of the Flash runtime, and SilverLight 4, it was necessary to use 3 rd party tools to accomplish some of these tasks correctly
    Page 21 of 59
  • Dynamic Sizing and Placement
    • How much space content should take and where it should be placed on the screen is defined by language, locale and font
    It is unlikely that a translated message to another language will ever take the exact same amount of screen space. Some locales will expect form headings and scroll bars to be in drastically different places. Page 22 of 59
  • Challenges: Sizing and Placement
    • Therefore, you can never assume an absolute font size. Some glyphs cannot be accurately displayed below approximately a 12pt font
    • You can also never assume that two strings will concatenate in the same way in different languages.
    • Care must be taken with text inputs embedded in a string
    Page 23 of 59
  • Challenges: Sizing and Placement
    • As noted, strings represented in different languages and different fonts take different amounts of space to display
    • Not only can you not assume the size of a field, you must also not assume absolute positioning of other fields
    • Sizing and placement must be handled fluidly
    Page 24 of 59
  • Challenges: Sizing and Placement
    • Screen shot of app with fixed size
    Page 25 of 59
  • Challenges: Sizing and Placement
    • Dynamic sizes but not dynamically positioned
    Page 26 of 59
  • Challenges: Sizing and Placement
    • Resized and repositioned
    Page 27 of 59
  • Customizing Views
    • Customizing views per locale is the ultimate expression of localization
    How do you manage to have customized views per locale and not allow it to become a nightmare of custom builds and custom code? Page 28 of 59
  • Solutions
    • So, how do you define an effective client side architecture for i18n and L10n application?
    • You need to start by separating meaning from display
    • For example, Unicode maps characters. It allows others to decide how those might appear on the screen
    Page 29 of 59
  • Number
    • 1 is a number, it represents a count of some abstract item. We can represent it a variety of ways but it has a known meaning:
      • 1
      • 1.0
      • 1,0
      • 1.00000000
      • One
      • Uno
    Page 30 of 59
  • Numbers
    • Similarly 3 quarters of a whole has a meaning, regardless of presentation:
      • .75
      • ¾
      • 0,75
    Page 31 of 59
  • Dates
    • Dates also represent a point in time relative to another point in the past. While the choice of fixed point may vary from culture to culture the meaning of a date is the same:
      • 03/14/2010
      • 14/03/2010
      • The fourteenth of March, year Two Thousand and Ten Anno Domini
      • 29, Rabi' al-awwal ( ربيع الأول ) 1431
    Page 32 of 59
  • Reference Data
    • Even non-simple types share the same trait. For example, the biological sex of an individual has a specific meaning which is conveyed regardless of the word used to describe it
      • Male or Female
      • M or F
      • Macho o Hembra
    Page 33 of 59
  • Meaning
    • In all cases there is an underlying meaning which is being shown in one of a variety of ways
    • Understanding the meaning of data separate from the way it is shown or the way it is entered is a major part of the solution for client internationalization problems
    Page 34 of 59
  • Meaning
    • In other words, we need to separate the idea of presenting the data from the meaning
    • This fits inline with the idea of a multi tiered approach to client-server architecture
    • ..which fits in very well with my talk.
    Page 35 of 59
  • Tiers Page 36 of 59
  • Solving the problem
    • The major focus of our i18n work is the presentation tier.
    • Storing and saving data with meaning in mind, and never with format
    • Relying on the presentation tier to format and interpret incoming format into raw data.
    Page 37 of 59
  • Why?
    • Well, let’s consider the alternative
    • Does it make sense at the data level?
      • Once data is stored with format it becomes a constant struggle to interpret it for different locales. However, your data layer needs to be capable of storing i18n info.
    • Does it make sense at the logical level?
      • The logical level should do operations on data. To me it is very important that the data is already normalized before the logical layer touches it. The biggest challenge is not messing it up here.
    Page 38 of 59
  • Example Solutions
    • These examples are Flex-based, however, the concepts are not Flex-specific.
    • The concepts, not the language or implementation are important here
    Page 39 of 59
  • Adobe Flex Primer
    • Adobe Flex is a technology designed to build the presentation tier of rich Internet applications.
    • These applications resemble client server applications more than web applications
    • They are executed in a virtual machine on the client.
    Page 40 of 59
  • RIA
    • RIAs continue to advocate separation of view from data.
    • This concept make RIAs extremely practical for our purposes
    • A developer can create a view which automatically monitors and reacts to changes in an underlying data model.
    Page 45 of 59
  • Data / View Interaction
    • That means that, in general, a developer interacts with data.
    • The view of that data is represented by one or more classes and can vary without changing the underlying logic.
    Page 46 of 59
  • Form v Function
    • It is viable to say that, when coded in this manner, the concepts of form and function are decoupled.
    • You can define the functionality of a component or view. That functionality can remain in tact regardless of how you choose to display it on the screen.
    Page 47 of 59
  • Getting to Meaning
    • So, why does this make sense for an i18n application?
    • Because developers can interact with meaning. The formatting of that meaning becomes part of the view.
    • As the form and function are separate, you can have multiple, very distinct views of the same data without rewriting the functionality in any way
    Page 48 of 59
  • Examples
    • Let’s take a look at some of the specific tools available to the Flex developer which aid in this goal
    Page 49 of 59
  • Data Binding
    • Data Binding is a key concept where the view monitors data for changes.
    • When a chance occurs, the view updates as in this simple Currency example
    Page 50 of 59
  • AutoLayout
    • The ability to auto size and auto layout content are huge advantages when considering i18n.
    • This is a very quick example of dynamic layout
    Page 51 of 59
  • External Resource Files
    • Most modern frameworks allow you to define your externalized strings in property or resource files.
    • Those files can be added to a project at compile time or loaded at runtime as needed
    Page 52 of 59
  • View Skinning
    • View Skinning is the first place that one can truly begin to understand the message of form and function separation
    • When skinning a component or view it is possible to completely change anything visual about the component without ever changing the functionality
    Page 58 of 59
  • Contact Information Michael Labriola http://twitter.com/mlabriola Page 59 of 59