Using system fonts in Flex based applications

This article was originally written in English. Text in other languages is provided via machine translation.

When working with Flash based applications, there are issues with fonts since the specified fonts might not exist on the user machine. The problem is compounded when you have international users each of whom might be working on multiple operating systems (Windows, Mac), multiple versions (Win XP, Win7, Win8, Mac 10.6, and Mac 10.7), multiple locales (French, Italian, Spanish, Russian etc) and thus having different available system fonts. One option to streamline the experience would be to embed fonts – entire fonts or specific subset of characters from a font. The other option would be to use the operating system’s default fonts.

Adobe’ installer and licensing components (which goes out with Master Collection and almost all point products like Photoshop, InDesign, and Illustrator) uses the later approach. The component identifies user’s locale from OS locale and then picks up a font from a prioritized list of pre-defined list of fonts for that locale. The font specification file has been externalized so that any future changes around font names could be easily verified and accommodated without making a code change. Further the list has been segregated based on font fall-back for text appearing in software UI and for text fields in the application.

The list of fonts for each locale is listed towards the end of this blog post. Getting to this list has not been an easy task and there has been a huge effort from multiple teams for this. Some of the hurdles that the team had to clear were –

  1. Getting an exhaustive set of fonts used in each locale and OS
  2. Segregating the fonts according to UI and Text fall-back
  3. Putting those fonts and fall-back logic together in an xml file
  4. Identifying the font’s priority so that same logic works across all OS platforms and versions
  5. Working with linguists to test each screen with applied fonts for readability and aesthetics
  6. Iterating #3 and #4 based on linguist’ response and ultimately arriving at final font fall-back xml file
Locale UI Font Fall-back Text Field Font Fall-back
Japanese Hiragino Kaku Gothic ProN W3, Hiragino Kaku Gothic Pro W3, Meiryo UI, Meiryo, MS UI Gothic, MS Gothic, _sans Hiragino Kaku Gothic ProN W3, Hiragino Kaku Gothic Pro W3, Meiryo, MS Gothic, _sans
Korean AppleGothic Regular, Malgun Gothic, New Gulim, Gulim, _sans AppleGothic Regular, Malgun Gothic, New Gulim, Gulim, _sans
Chinese Traditional Heiti TC Light, Lihei Pro, Microsoft JhengHei, MingLiU, MingLiU_HKSCS, _sans Heiti TC Light, Lihei Pro, Microsoft JhengHei, MingLiU, MingLiU_HKSCS, _sans
Chinese Simplified Heiti SC Light, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Song, _sans Heiti SC Light, STXihei, Microsoft YaHei, SimSun-18030, SimHei, SimSun, MS Song, _sans
Russian, Ukrainian Lucida Grande, MS Sans Serif, _sans Lucida Grande, MS Sans Serif, _sans
All others * Lucida Grande, Segoe UI, Tahoma, _sans Lucida Grande, Segoe UI, Tahoma, _sans

All others include French, German, Spanish, Italian, Brazilian Portuguese, Netherlands, Swedish, Danish, Finnish, Norwegian, Czech, Polish, Turkish, Hungarian, Romanian, Slovenian, Slovak, and Croatian.
P.S: These font fall-backs were defined and tested for Flex 4.5.1 SDK with Spark components (using TLF, Text Layout Framework)

One caveat to note here is that system fonts keep changing from time to time, which usually amounts to new fonts, or new versions of existing fonts, but sometimes results in existing fonts becoming deprecated. In general, though, linguistic support in OSes, in terms of glyph coverage in bundled fonts, gets better, not worse.

Globalization Myth Series – Myth 3: Language support should be limited to the official language(s) of a country

This article was originally written in English. Text in other languages is provided via machine translation.

Problem statement

In the globalization field, we often observe cases where companies mix up the usage of countries and languages when delivering products to their global customers. Assumptions are often made that people living in a country should receive services in that country’s most common language(s) – such as – Japanese in Japan, English in the United States or Russian in Russia. Good companies will even support multilingual situations like Belgium and Switzerland, which support multiple official languages – but is it really enough?

In this blog article, we argue that the concepts of “Country” and “Language” should be treated apart – even though they are related.

Languages have no borders

Historically, languages have spread around the world through immigration, invasions and colonization. This is why Spanish is spoken in South America, English in the United States, French in Senegal and Canada – just to name a few examples.

Languages haven’t been limited to their homelands in a long time. For example, Spanish and Portuguese have spread to the point where most of their native speakers are found outside the Iberian Peninsula. Only 8.95% of Spanish speakers are actually Spaniards [1]. We could argue that there are different flavors of Spanish, Portuguese or French, but, in essence, these languages are the same and they are not confined by country boundaries.

Twitter is a great tool to visualize languages spoken around the world. Eric Fisher created a cool language map using Twitter data [2], which clearly shows borders being redefined. Catalan appears on the map and multilingual countries like Belgium disappear under France and The Netherlands.

Map of languages as used with Twitter

Figure 1: European Language Map – Author: Eric Fischer

Official languages leave some major gaps

Many companies launch products/services in a country and limit localization and features to the official language(s) of that country. In software, a typical example is to create a new product for the American market and limit functionalities to English-speaking users’ needs. But this is usually not enough – even if the market is limited to the United States.

Recent U.S. Census data shows that 60 million (or 21%) of Americans aged 5+ years old speak another language than English at home. Spanish takes a big part of the pie with 25 million, but languages like Chinese, Tagalog, French, Vietnamese, German and Korean are each well above the 1 million speakers mark [5]. This is very understandable considering the immigration history of the country.

In addition, the U.S. welcomed 59.7 million international visitors in 2010 [6]. Of those, 33.4 million were from Canada and Mexico and 26.4 million from outside North America. Knowing that these foreigners spend on average $4,000 during their stay, this market segment shouldn’t be ignored.

Using the Greenberg’s index, which measures the probability that 2 persons in a country would speak the same language, The Economist shows that language diversity is happening in all countries around the world and, especially, in nations other than the United States, Russia and China [7]. Also, Ethnologue.com is an excellent source of data around language adoptions.

This diversity is also visible in Adobe’s analytics. Thanks to the Adobe Digital Marketing Suite and our Dynamic Language Delivery technology, we are able to capture the languages in which our worldwide customers would like to receive products and/or documentation. Figure 2 shows the language requests for Adobe Nav in the United States. Data collected with this small application basically confirms the diversity of the population in the U.S since languages such as Spanish, Arabic, British English, Korean, Simplified Chinese, Traditional Chinese, Dutch, Russian and Turkish are all requested by users located in the United States.

Languages expected by DLD users

Figure 2 – Unsatisified language requests for Adobe Nav in the United States

Language diversity in any country is the chief reason why software products should be developed with a global audience in mind. Even if the user interface or documentation is left in English, desktop, web and mobile applications should at least be able to input, display and print characters for most languages.

Similarly, we have been able to capture data about the preferred languages on Adobe.com. This data confirms that countries and languages are two separated concepts – and while most customers from a country read the content in an official language, a big chunk of visitors still prefer to read the content in a different language. For example, with the Action Script Reference (ASR) guide, we noticed that, in Russia, only 68% of the Flash developers prefer reading the documentation in Russian versus 31% in English (a non-official language) and 1% in other languages. Similarly, numerous Flash developers outside of Russia choose to read the ASR documentation in Russian (See Figure 3).

Distribution of Russian Action Script Readers around the world

Figure 3 – Country distribution of Action Script Reference read in Russian language

This is another example why assumptions between countries and languages shouldn’t be made.

As people continue to become more mobile, it is critical to separate the concepts of country and language. This mobility is what spread languages beyond borders and creates the need to have languages supported everywhere.

A language is a customer preference, which can’t be constrained by country borders.

Consequently, if languages don’t have borders, flags shouldn’t be used to represent them as often seen on web-sites. Flags are meant to represent political entities [3]. A common example is to represent the English language with the British “Union Jack”. But it’s not culturally sensitive for English speakers from Australia, India or United States. Some have addressed the problem by mixing multiple countries’ flags into one although it’s making the situation even more confusing. The flag below (Figure 4) represents the German language (spoken in Germany, Austria and Switzerland) and we can imagine how convoluted the Spanish language flag would look like since Spanish is the official language in 14 countries [4] and spoken in many more!

Using flags to represent languages can become complex

Figure 4 – Flags and Languages (WikiMedia)

Take-Aways

In summary, we offer 3 take-aways to consider when launching a product globally:

  1. Differentiate the concepts of “country” and “language”. As such, don’t use flags to represent languages.
  2. Don’t limit support to the official language(s) of a country/region. Some languages may need to be supported even though they don’t have official status.
  3. Languages don’t have borders and need to be supported globally. Capture users’ preferred language(s) so you can serve them in their language independently of their location.

References: