Join Us: 3rd Adobe Experience Manager Multilingual Content Special Interest Group Meeting

The Multilingual Content Intelligence team at Adobe is excited to host our third Adobe Experience Manager Multilingual Content Special Interest Group (SIG) meeting on Thursday, Nov. 7, at our headquarters in San Jose. Our program this time is on Digital Asset Management (DAM), and we plan to focus on how DAM can be used for multilingual purposes. During the meeting, we’ll also have a Multi Site Manager (MSM) review session to share feature enhancement plans for future releases.

This is a great opportunity to understand basic concepts of DAM and related best practices in a multilingual context. Attendees will also rub elbows with our Adobe experts, share their experiences and challenges, and network with peers from various industry leading companies that are putting Adobe Experience Manager to use.

The details:

Date: Thursday, Nov. 7, 2013

Time: 8:30 AM – 4:30 PM PST
Address: Adobe San Jose headquarters
345 Park Avenue
San Jose, CA, 95110

The event is free, but you must register in advance to attend. For registration, please visit: https://adobesig.eventbrite.com

For more information or any questions, you’re welcome to ping me at: seunlee at adobe.com

We hope to see you next week!

Seungmin Lee

Sr. Program Manager

Embracing Indian creative workflow

Any kind of digital creative content – whether it is a simple newspaper advert, or a large hoarding, or laying out a complicated magazine or a newspaper – comprises of handling text. Creating such a content for regional audience with software not supporting Indian scripts is like driving a left-hand-drive car in India – not comfortable at all.

How does a customer-oriented company like Adobe approach these users in the Indian subcontinent? Internal research shows that users in India are comfortable using English interface for software – what’s really needed is the ability to compose and handle text in Indic scripts, more so in text publication workflows.

While the publishing workflow is largely based on Adobe InDesign and we started supporting 10 of the most popular languages in Adobe InDesign CS6, there was a need to bridge the gap with other publication workflows utilizing Adobe Illustrator and Adobe Photoshop. Adobe did so with the latest release of Creative Cloud products by introducing Indic script support in Photoshop CC and Illustrator CC. Users can now compose their text in 10 regional languages, generate world class print output, and still be within their beloved Adobe environment.

The Creative Workflow

Common workflows in creation of digital content involve extensive flow of content cross InDesign, Photoshop, and Illustrator. Photographs are clicked with the digital cameras and are beautified in Photoshop. These are brought into Illustrator and converted to vector images and are further used as a part of an art work. Small sections of these images (even raster forms) could as well be converted to form a brush stroke in Illustrator CC. A complex artwork including raster images and vector art is finally rendered to print through an InDesign document, which blends this graphic with text stories to give a phenomenal impact to readers.

Such meshed workflows often use text at various places, and the users ought to be able to work with that text whenever needed in the workflow. They don’t want to wait until the artwork is placed into InDesign for them to be able to insert text in regional languages.

Covering the entire flow

As a creative professional, one always wonders if they could do some raster handling in Illustrator, or some type handling in Photoshop, or some vector handling in InDesign. All of these are possible with Adobe software today, and that makes using these three in our publication workflows so very seamless. Not only that, we also want to create that beautiful type effect in Illustrator using Indic characters in our regional language. We want to give titles to our Photoshop banners in our own language. And much more…

With the latest CC release, joining the excitement of the amazing features, Photoshop and Illustrator also provide support for Indic scripts as in InDesign.

What’s more? The overall experience with Indic scripts has been made far richer with a number of bug fixes.

Adobe Fonts:

In addition to extending Indic script support to Photoshop and Illustrator, we appreciate the need for Adobe fonts in languages other than Hindi. Well-designed Unicode fonts that support Indian scripts can enhance productivity and cross-compatibility of content created by creative users, including the content creators, the designers, and the editors. We thus took this initiative of providing this beautiful set of fonts, starting with Adobe Devanagri.

  1. Adobe Devanagri was introduced in CS6 timeframe, and has now been extended to include the Marathi script as well.
  2. A completely new font, Adobe Gurmukhi has also been introduced. This will come pre-installed for users to start creating content in Punjabi. Also, fonts for more Indian languages are on their way!

To read about the Indic support in InDesign CS6, please read this article.

The Problem with Localizing Software for Multiple Platforms

Adobe has a long history of developing products for multiple platforms, be it desktop applications like our flagship Creative Suite applications or newer touch applications like Photoshop Touch. Most of our desktop apps have been built for both Windows and Mac and newer applications continue on this trend with support for iOS and Android including Tablet and Phone form factors for both.

Of course this would not have been possible without the careful efforts of the engineering team to largely maintain a single code base for all platforms.

While having a single code base has obvious benefits, in the UI layer it is often important to have platform specific variations for better usability. Each platform usually has a specific convention for referring to system menus, short cut keys and UI elements. For example on a windows platform a UI String could be – “Select a media file via the Browse button or enter a valid pathname.” and the same string for the Mac Platform could be – “Select a media file via the Choose button or enter a valid pathname.”

This means that translatable UI strings may have many variations in the source language depending upon which platform they are intended for. This is what our globalization group usually refers to as ‘Platform Variance’. Localizable strings are essentially multivalued entities. Each localizable string has an identifier and multiple associated values each of which can be selected based on certain criteria. The most obvious and commonly used criteria is the UI locale of the application but it need not be the only one. Platform too can decide the value of a string.

Platform variance support is not just useful for handling terminology differences for referring to system UI elements, it also helps adapt strings for different screen sizes. Modern application are designed for supporting multiple device form factors like tablet and phone with the UI being tweaked for each platform for best user experience. Platform variance in this case can be used to support longer strings for the Tablet view and shorter strings for the Phone view.

Yet another area where platform variance support could potentially be useful is in having different localizable values for a Pro version versus a Consumer version of the application.

However, localizing strings with platform variant data is a problem. The problem is two fold, one is in managing the processes and project schedule to allow for agile localization and simultaneous release for all target platforms. The second aspect is technically supporting the platform variance in both programming libraries and translation tools. Many tools and libraries assume a single value for a source and a target string, but in case of platform variance not only can there be multiple source and target values for a string there need not be a one-to-one correspondence between source and target values. There may be multiple platform variants for a source string that map to the same translated/target value or a single source string may need to be translated differently based on platform for the target locale. For example:

  • en_US: “Please close the dialog and start over.”
  • default fr_FR: “Fermez la zone de dialogue et recommencez.”
  • Windows fr_FR: “Fermez la boîte de dialogue et recommencez.”

Since I am part of the globalization tools team here at Adobe, the remainder of this post I describe the problem more from a technical tools and libraries perspective, drawing from my experience. The process problem is also pretty complex and would probably take a much longer blog post to discuss. In fact there’s a related one already on this blog, see – link.

Platform Variance Support in Libraries

Ideally the globalization libraries/APIs used in the code to manage externalized strings and the corresponding storage formats for the externalized data should have a notion of a platform variant value for each string. There should be a way to request a string value for a specific locale and platform along with a provision to fall back to a default value in case a platform specific value is not specified.

As an example, the Java ResourceBundle API supports selecting a bundle by ‘Locale’, there is no explicit mention of a ‘Platform’, but the ‘Locale’ itself is extensible to support variants. The variant mechanism in the ‘Locale’ can be used for supporting different platforms and there is also a fall back mechanism. At Adobe we have a custom developed cross platform library called ZString for managing externalized strings with explicit support for platform variance.

Platform Variance Support in Translation Tools

Most translation management systems (TMSs) have a one-to-one model of source strings with matching translated strings for each locale. This assumption is behind the architecture of the TM matching algorithms as well as the design of the translation workbench. A typical translation workbench usually offers a side by side view of source and target strings, but only supporting a single source string corresponding to a single translated value.

Typical Translation Workbench

A typical side by side view of Source and Target content in a translation tool

We are still searching for the ideal solution to this problem. For managing the TMs a possible workaround using existing systems is to have duplicate entries in the Translation Memory (TM) or a separate TM for each platform.

However, translators are still constrained by the view presented by their translation workbench. A possible solution to allow translation vendors to provide platform specific translations is to duplicate all the source strings for each possible target platform. The source value for the default platform can be used as the source value for all other platform unless the application UI already specifies a value for a specific platform in which case that is used. Now the translator can provide different translations for each platform if required. This workaround however seems to be a significant amount of additional work for the translators. Some optimization is possible by translating a single platform first and leveraging translations for all the other platforms.

In an ideal scenario the translation workbench would provide a side by side view of all platform variants for the source string and the target strings. With the ability for the translator to remove variants from the translated string where they are not required and propose variants for the translated string even if the source string does not have any. This would allow translators to work through the source content in a single pass, editing leveraged translations, providing new translations where required and proposing platform specific translated values as appropriate.

An approximation to this ideal view is an Excel sheet with each source string being represented in a row and having a separate column for each platform for both source and target strings. With blank values in a platform column signifying that the default translation is to be used for that platform and non-blank platform entries being used for the platform specific translations.

Ideal Translation Workbench

A proposed translation workbench view allowing simultaneous translations for multiple platforms

We are still experimenting to find the optimal solution for our needs, that offers flexibility to translators and yet leverages our investment in existing translation tools and processes. The goal is to be able to support faster agile release cycles with all platform releases happening simultaneously.

I think this is a good forum to ask our blog readers if they have faced similar problems and the solutions they have developed to deal with it.

Generating help in multiple locales using Adobe RoboHelp 10

Adobe RoboHelp software is an easy-to-use authoring and multichannel, multiscreen help publishing solution.

Using RoboHelp 10 -

  • You can deliver content to iPad and other tablets, smartphones, and desktops using output formats such as multiscreen HTML5.
  • Working in multi-author environments using next-generation collaboration and review features.
  • To personalize and optimize content for relevance and search.
  • Easy development of context-sensitive help with usability enhancements.

Adobe RoboHelp 10 supports output formats as shown in graphic below:

1

The help author has to concentrate on the content and need not to worry about different output formats as it would be handled by RoboHelp itself. They have to simply select the output formats and generate with required options.

How to change default Language setting?

RoboHelp 10 is shipped in English, French, German and Japanese locales but the help can be generated in many more languages.

Help authors many a times face such scenarios when they have to generate the output in multiple locales.

When you create a new project the default Project language is same as that of installed RoboHelp.

This implies that the same language is used by RoboHelp to show any text/LNG Strings in the output apart from main authored content spelling checks, and dictionaries and in generating smart indexes. Besides help content there are a lot of default text elements in output runtime user interface of help systems like table of contents, index, glossary, search, no results found etc. This is a big list of such strings which can be there in any help system commonly called LNG strings.

But if you want a different language for these then use can select it from the Project settings dialogue. For example if you are using French RoboHelp and want Spanish language settings then you can go to “File > Project Settings” and select Spanish from the Language dropdown. Refer to image below:
2

4

3

RoboHelp provides fine control over language setting and besides project users can define language for a particular topic or even for a particular paragraph.

To change language setting of a topic open “Topic Properties” dialog and change the language from dropdown in “General” tab.

5

 

 

 

 

 

 

 

 

For changing the language for a particular paragraph open the “Paragraph” dialog and define new language from here.

Language defined at the paragraph level takes precedence over language defined at a topic level. Language set at the topic level takes precedence over language defined at a project level. Language defined at the project level can never take precedence over language defined at paragraph level. If multiple languages are defined at the project, topic, and paragraph level then the effective language as per the precedence is used for dictionary or thesaurus association and for spell checking.

Users can change this default language to following 36 languages:

Bulgarian(Bulgaria), Catalan(Spain),Croatian(Croatia), Czech (Czech Republic), Danish(Denmark), Dutch(Netherlands),English(UK), English(US), Estonian(Estonia), Finnish(Finland), French(Canada), French(France), German(Germany), German(Switzerland), Greek(Greece), Hungarian(Hungry), Italian(Italy), Japanese (Japan), Korean (Korea), Latvian(Latvia), Lithuanian (Lithuania), Norwegian Bokmal(Norway), Norwegian Nynorsk(Norway), Polish (Poland), Portuguese(Brazil), Portuguese(Portugal), Romanian(Romania), Russian(Russia), Simplified Chinese (China), Slovenian(Slovenia), Spanish(Spain), Swedish(Sweden), Thai (Thailand), Traditional Chinese (Taiwan), Turkish(Turkey), Vietnamese (Vietnam)

So it is interesting to note that while we are localizing Adobe RoboHelp in 3 languages, we are enabling our users to create help with ample support in 32 more languages.

Going a step further -> Editing LNG strings for customized needs

While as part of RoboHelp localization we provide LNG strings in 36 languages, users can also modify these strings for any language to suit their needs.

The LNG strings can also be edited for any customization needs. This can be done from File > Project Settings > Advanced button > LNG file tab

6

All the strings are listed in the LNG File tab under different sections like WebHelp, AIRHelp etc. The desired string can be edited by selecting and clicking on Edit button. In this way help authors can also edit the LNG strings to customize existing strings.

 

How to create multilingual WebHelp from RoboHelp?

  1. Create a project in RoboHelp.
  2. Create separate topics for each language.
  3. Create separate table of contents from above topics for each language.
  4. Also create separate index and glossary for each language
  5. From the Single Source layout (SSL) pod open the WebHelp and click on content categories.
  6. Create new categories by clicking on New button and rename it after any particular language.7
  7. Each content category is now shown as a separate language. Select it and set the language specific Table of Contents, Index, Glossary and language.
  8. 8Now generate WebHelp and open it in browser.
  9. Select any particular language from the category dropdown.

9

 

Please note that the system you intend to open the localized help should have the locale specific code pages installed.

Authors :-
Sumer Singh – Lead Quality Engineer
Vinay Krishan Sharma – Program Manager

Adobe RoboHelp homepage

RoboHelp: Recommendation for creating localized Microsoft HTML help which is not fully Unicode compliant

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

Technical help authors can use RoboHelp 10 to create help in multiple formats (like Webhelp, FlashHelp, AIR Help, MultiScreen HTML5 and Microsoft HTML etc.) and locales.

While generating localized Microsoft HTML help (CHM help) with English locale settings using RoboHelp, Help authors might face following issues:

  • CHM Help output is not getting generated
  • The Table of contents (TOC) entries get seen as question mark(as shown in below screenshot)
  • The Topics authored in the Help are not visible when viewed and an error is shown: “This program cannot display the webpage” (as shown in below screenshot)
  • Index for double byte languages may appear garbled

The above mentioned issues are not encountered while:

  • Creating other help formats using RoboHelp10.
  • Generating Microsoft HTML Help in the languages with code page 1252.
  • The languages are English, French, German, Italian, Spanish, and Swedish.

These issues are encountered while:

  • Generating Microsoft HTML help for rest other locales. (e.g. Russian, Japanese, Chinese Simplified and Korean)
  • Even for locales which seems to be similar to English and fall in code page 1250 like Polish, Hungarian, Croatian, Czech Albanian and Romanian

The reason for these issues is that HTML Help is not fully Unicode compliant.

For the help authors who want to generate localized (take Chinese Simplified as example) Microsoft HTML help we would recommend using the following settings -

  1. (Recommended) Change the language for *non-Unicode programs to Chinese (Simplified,PRC). There is no need to change the display language to Chinese as only changing system locale should work. Also keep the project language as Simplified Chinese.

Control panel settings

Change current system locale

*language for the non-Unicode programs can be changed from

  • Windows 7 -“Control Panel” >”Region and Language” >”Administrative” >”Change System Locale”
  • WinXPP-SP3- “Control Panel” >”Regional and Language options” >”Advanced” >”Select a language”
  • WinXPP-Sp3 users’ also needs to install the Simplified Chinese language pack.

2. If its required to keep English locale settings for some reason (generating help in multiple locales on same machine) then follow the below steps (also refer below screenshots) -

  • Create a new project with Filename\Location in English and keep project language as Simplified Chinese
  • Create topics with name(Title and Filename) in English and topic content in Chinese Simplified
  • Create TOC and rename the TOC entries to Chinese
  • Index and “See also” also needs to be kept in English

Step 1

Step 2

Step 3

We hope that this blog helps our customers facing issues generating Microsoft HTML help in multiple locales. We also endorse other help formats like WebHelp , Flashhelp and AIR help which are fully Unicode compliant.

Ready For The Community: Adobe Translation Center (ATC)

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

A single gateway into Adobe’s Community Translation “universe”

November 2012 marks the month when Adobe’s Globalization group is launching the “Adobe Translation Center” (ATC) at translate.adobe.com. For Adobe’s customers and fans, ATC will be the single access point to provide feedback and improvement ideas for existing translations in “Adobe languages”, the shipping languages of an Adobe product. At the same time, the center will also be the place where our vibrant and growing translator community explores – in a collaborative fashion – opportunities for “community languages”: Languages that are in high demand by their speakers, but not delivered as part of our product offerings.

ATC Landing Page

ATC landing page

So far, our community translation “universe” consists of two planets, reflecting its current two main focus areas:
Adobe Translation Center
itself is now offering functionality allowing fans to collaborate on user interface (UI) translation (formerly this has been available through Adobe Translator). The activity around UI translation has been growing quickly, supported and used by several hundred contributors.
The Adobe TV Community Translation project is ATC’s very successful bigger twin: More than 2,500 translators have already translated subtitles for more than 14,000 minutes of video to make educational, entertaining, and helpful content available in a growing number of languages.

Not too long ago …

In November 2011, this blog presented the success case of how fans and users enabled Adobe Business Catalyst (BC) to ship with an additional language UI in Dutch, entirely translated by the BC partner community. The motivation driving this effort was the interest to better serve the partners’ customers in that language (BC with Dutch UI).

Since then, the ATC product team has been busy at work and put a significant effort into improving the Translation Center’s “look & feel” and its functionality. Entering feedback and translation suggestions is now possible intuitively and in a visually pleasing interface that follows the overall Adobe.com experience. As with all Adobe products, agile development methodologies are allowing the team to react to user feedback: Even though ATC is now launched, we still consider it to be “work in progress” (as opposed to “set in stone”) and are eager to hear what the community desires in order to be more productive or to have a more delightful collaborative translation experience.

Product Explorer

Product Explorer

“Community Translation” at Adobe

At Adobe, community translation refers to the process of enabling our users to translate content in a collaborative environment, assisted by professional translators or moderators. Types of content available for community translation today are videos (through Adobe TV) and software user interface (through the functionality within Adobe Translation Center). In the future, we expect community translation to expand into areas like documentation or user forums.
Ideally, collaboration and interaction between contributors should make community translation a rewarding and fun experience. We are confident that our tools will contribute to such an experience, so that lively and passionate communities will be developing and thriving around them.

Why does Adobe promote community translation?

Adobe has a long history related to localization and globalization. Our products are reaching people all over the world and allow them to express their creativity, regardless of their native language or the locations where they live and work. No matter what language we are using, when speaking to our users, we are always deeply impressed, how important our products are for them and with how much passion they speak of them.
At its core, Adobe is a company as international as our users. We have offices around the world, and in all our teams worldwide one finds colleagues from all over of the globe: The desire to serve all our international customers with excellence, is deeply engrained in ourselves and is reflected in our daily work.

Adobe’s community translation program is one means to get another step closer to the goal of shipping “world-ready” or “truly global” Adobe products, based on demand expressed and input provided by our customers and user communities around the world.

Lightroom Polish

Lightroom Polish project

Why is Adobe building the Adobe Translation Center?

In the past, Adobe pioneered a few community translation programs, resulting in great responses from our users. After a series of pilots, we are now beginning to unify all of Adobe’s community translation efforts in a single place: Adobe Translation Center (ATC).
With engineers, user experience designers, and product managers, ATC has a dedicated product team whose goal it is to provide the best experience for translators from different communities. Building and maintaining such a platform represents a sizable investment for Adobe. However, we believe that the long term gain resulting from a better understanding of our international users, will be worth the effort, time, and investment.

Benefits of community translation

The cooperation between Adobe and its trusted professional translators has been working very well for many years now. This joint effort will continue to be a cornerstone of Adobe’s international success. However, there are some aspects of product translation where the involvement of the user community might have advantages over traditional workflows or may lead to something new altogether.

Feedback and translations through people using our products every day

It is impossible for professional translators to be experts for all products or areas they are translating for. While the professionals’ work for sure will always be correct, the everyday product user might – from time to time – have an edge to provide up-to-date translations.
In the past, we have experienced that a few translations in our products do not reflect the prevailing use of terms by our customers. In this area, we want to use the opportunity to make our translations match our users’ needs and expectations. With similar intent, we are leveraging mechanisms like community voting or commenting, so that translations match the expectations of the community at large and we are not representing isolated feedback.

It is important to note that there will be no “automatic way” for a community translation to enter the final product with review: In order to maintain the quality our products are known for, there will always be trusted moderators and reviewers close to the community who make the decision which string is ready for inclusion in the final product. By the way, only with the help of our partners on the professional translation side, will we be able to achieve scalability and support for the numerous community languages.

Evaluation of more Adobe product languages

ATC Lightroom

ATC Lightroom Page

Historically, Adobe has shipped in languages that have been representing our core markets: North America, Europe, Japan, Asia. That is a good number of languages already. With now the entire planet as the potential market-place for our products, however, we are constantly facing the question which languages to ship our products in. Currently, it is not possible to translate into all languages of the world due to logistics, cost, and incomplete information about addressable market size.
It is exactly the question which language to take on next, where community translation will help finding an answer by reversing a common mechanism: Instead of having to make assumptions about market sizes and demand for translated products before we ship them, ATC is empowering our users to indicate which languages are important to them and, hence, to us: Community membership size and translation speed for a product language, will be crucial indicators.

Shipping product languages vs. candidates for new languages

There are two different groups of languages which we are making available for community translation:

“Adobe languages” are all languages that are current shipping within a product. For “Adobe languages”, users can provide alternative translations if they discover typographic errors, if a string is too long or clipped, or simply, if they would prefer a different translation over the one that is currently appearing in the product. In our tools, shipping languages will usually appear as 100% translated and reviewed in our tools. Nevertheless, Adobe is looking forward to the community providing us feedback for those languages.

“Community languages” are not shipping with a particular product and we we make them available for community translation. For those languages, there can be different reasons why we are adding them to ATC: A passionate user community that we are aware of in a particular country, or repeated user requests to have a product available in their language, or business reasons on the Adobe side.

Full disclosure: To be perfectly clear, a “community language” which is 100 percent translated by a passionate community will not automatically be shipping with a future version of the product. The business decision which languages to ship, will remain the sole responsibility of the products’ stakeholders. Both the community and Adobe Translation Center team will always have to defer the final decision to the product team.

Why would users engage in community translation?

Lightroom Translation

Lightroom Translation

Users who participate in Adobe’s community translation program have a chance to get involved in the development of their favorite tools. They can directly affect the translation of a product through submitting suggestions.
And even if the translation into a specific language has already been completed, users will continue to have a channel to express their opinion (about translation quality). Or they can help us improving the product through reporting localization bugs in a convenient interface, without the need to go through complex bug reporting systems.

By joining the Adobe community translation program, users will strengthen their local community’s role and impact. In return, they will receive more attention. and, moreover, they have a good chance of influencing the future of an Adobe product, maybe even beyond localization support.

Community translation is already a common way for many companies (Adobe’s peers in the software industry among them) to explore new ways to interact and engage with fans, users, and customers. For Adobe, that type of interaction is one way to better hear the voice of our customers.

We strongly believe that our products will continue to improve because we intend to listen to that voice …

Please visit (and “like”) our Facebook page or start following us on Twitter.

 

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.

Adobe Moses Tools now available for Windows

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

We have an update on the Adobe Moses Tools which we announced on this blog on May 11. The tools are now available in pre-built packages for Windows! Check out the download section of the M4Loc site to get the Windows packages and for documentation and other information about the tools.

Please download the tools and let us know what you think!

–Raymond Flournoy
Senior Program Manager
Translation Technology Team