Posts in Category "Technology"

AMT – Adobe Moses Tools Now Available

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

I’d like to announce that [tp no_translate="y"]AMT (Adobe Moses Tools)[/tp] are at last open sourced and available for download.

All code and documentation has been submitted to [tp no_translate="y"]M4LOC Moses[/tp] for Localization.

http://code.google.com/p/m4loc/

Prepackaged DMGs for OSX users can be found here:

http://code.google.com/p/m4loc/downloads/list

Source code for those interested in building on the tools and improving them can be accessed here:

http://code.google.com/p/m4loc/source/checkout

I would be psyched to hear from folks who download and use the tools and are looking to improve them.  It’s been a long road from jumping into the deep end with [tp no_translate="y"]Moses[/tp] until where we are today.  There’s still plenty to get done.  Let’s work on building that together.

Cheers!

Jeff

Adobe gave a presentation about Moses Tool Set on TAUS Asia Translation Summit 2012

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

[tp no_translate="y"]TAUS Asia Translation Summit 2012[/tp] was organized by [tp no_translate="y"]Translation Automation User Society (TAUS)[/tp] in cooperation with [tp no_translate="y"]China Center for Information Industry Development (CCID)[/tp] and [tp no_translate="y"]Translators Association of China (TAC)[/tp]. 80+ attendees from both product companies such as Adobe, Baidu, EMC, Google and Microsoft and LSPs participated in the summit held in Beijing on April 24 – 25, 2012, as well as the complimentary half day event [tp no_translate="y"]TAUS Open Source Machine Translation Showcase[/tp] held in the same venue on April 23. The summit provides attendees an excellent platform to share knowledge and experience in MT domain.

TAUS_2012_Beijing_PresentationI was invited by TAUS to give audience an introduction of what Adobe has done on open source MT. In my presentation, I shared how Adobe makes use of the open source MT tool [tp no_translate="y"]Moses[/tp] in its localization workflow. We developed a set of tools called [tp no_translate="y"]Moses Tool Set[/tp] to simplify the usage of Moses. By using this tool, the training process of Moses can be done in an easier and intuitive way. It consists of 4 features: [tp no_translate="y"]Corpus Clean Tool, Corpus Splitting Tool, Moses Training Harness[/tp], and [tp no_translate="y"]Moses Scoring Harness[/tp]. Each feature can not only work independently but be combined into a job which enables users to complete the whole training process in one click.

Many audience especially those from LSPs that just started their adventure of open source MT showed strong interest on the Moses Tool Set. It’s happy to see that seeking for ways to improve localization productivity is no more the responsibility only for the language service buyers. Some LSPs have also started their attempts in MT field. [tp no_translate="y"]Moses[/tp] is a good option for them because of its lower entrance cost. In the offline discussion, however, I got a lot of complaints from these potential Moses users about usage of Moses. For those who don’t dive deeply into statistical machine translation, Moses is too complicated to start with. Many parameters are required to generate a trained MT engine. Lack of a friendly user interface is another headache for them. No wonder the very first thing audience eager to know is where they can find and download [tp no_translate="y"]Moses Tool Set[/tp].

Actually, [tp no_translate="y"]Moses Tool Set[/tp] is an open source project. Both its installer packages and source codes are available in Google Code.

Collaborative Translation Helps Adobe Business Catalyst Add New Languages

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

Adobe’s Business Catalyst product is a hosted, “all-in-one” solution for building and managing business websites (see also Wikipedia.org). Out of the box, Business Catalyst (BC) provides support for five languages: In addition to English, it is being shipped in French, German, Spanish, Swedish, following the demand of its major and most important markets. A crucial role in the BC business model is played by the “partners” or “resellers”, who use the product to customize websites according to the needs of their customer groups.

In the past, BC continued to receive feedback from both their customers and their own sales organization that there was a high demand for more languages. The addition of such languages would enable the partners to start selling their business websites into more countries than are covered through the out-of-the-box languages.

Despite the partner feedback, the demand and the business case for new languages was difficult to measure or quantify for the BC team. In that situation, BC decided to use a new and  evolving infrastructure available at Adobe to leverage “community translation” in order to validate demand before committing to changes. Before we go into details, first some information about the initiative’s success and the surprising response that it received in some cases.

Initial Successes

It was just in June, that the five original Business Catalyst languages were posted publicly on a community translation site for user review and translation suggestions. For participants in the pilot, the tool to use was “Adobe Translator” (AT), an application giving them access to the BC interface strings and their translations. In addition to reviewing the “legacy” languages already included in the product, the community was given the opportunity to provide translations for additional languages. Initially, those included Danish, Italian, Dutch, Brazilian Portuguese, Romanian, and Slovenian, based on requests coming in from the BC partners. We expect that more languages will be added to this project over time.

Contributions as of Oct. 31

What happened over the next months was a textbook example of surprising and solid contributions coming from a community. Once empowered to work on the their favorite language, driven by the expectation to potentially improve their business, the partners accessed the translation tool and got to work. The table “Contributions as of Oct. 31″ shows a constantly increasing number of contributions for each month from June through October (the numbers represent words contributed per month and are not cumulative). Going into more detail and looking at the weekly contributions on the right, we can also identify two clear spikes of activity.

If we look at the table below, we can identify Dutch and French as languages that have reached 100% completion, meaning their translation has been completed. And indeed, the two spikes in the table above coincide with the points in time when Dutch (the first spike)  and French (the second one), reached translation completeness.

Words submitted on Oct. 31

In addition, it can be seen that there is also a significant activity, although not quite as “explosive”, taking place for Danish and Italian, two more languages not part of BC’s original set. German and Swedish are also receiving some attention, but on a reduced level.

Thus, within a very short period of time and with the help of their partners, BC is now in a position to add a language to their product that has not been shipped before, i.e., Dutch. The fact that BC was able to bring in their partners in such a convincing and effective way, represents a big success for the BC initiative, and for the concept of community translation.

Similarly, even though not completely translated from the ground up, the “completion” of French as a language already shipping, indicates that the community contributed quickly to close the gap between strings already translated (referring to already existing functionality) and strings yet to-be-translated (to describe BC functionality added in the latest version). Another part of the activity around French, was to review existing translations and to submit alternative or better ones.
The summary here is that, in addition to completing translations into new languages, the review of existing translations for both “old” and new languages turned out to be a task that the partner community actively engaged in.

BC partners are now finally getting into a position where they can start marketing their customized sites, built using Business Catalyst, into additional countries or regions. From their business perspective, it hopefully pays off that they invested time in the translation effort. Over time and where it makes sense, Adobe will open up more projects to the community and allow both review and translation for even more languages, be it “traditional” or new ones.

Takeaways: Why Did This Go Well?

There are a number of components that need to be in place to be successful in a project like this. Two of them have already been mentioned:

  • Required is a community that is willing to engage in such a collaborative translation effort.
  • It may go without saying, but since it is so crucially important, we are mentioning it again, a motivation or incentive for anybody willing to contribute must exist. Motivation can differ widely between different communities, and in this case of a comparatively small group (of BC partners), the incentive was to have the product in a new language, the potential reward being to increase revenue through providing a additional language interface to target an expanded market.

Business Catalyst Language Selection

There are more factors that had a crucial impact on the project’s success:

  • The single biggest motivational force that drove the partners to contribute until completion was achieved, is depicted in the screenshot to the left. In the language selection drop-down menu, you can read (in Dutch) “Dutch (translated by the community)”. Only if the community contributions eventually make their way into an application, does the community start to feel a sense of achievement. And only when progress becomes visible in this rewarding way, will it have be worthwhile for contributors to invest time (and their time is their money!) in translation.
  • Last, but not least, there is, of course, the architecture required to enable community translation. For that, Adobe is leveraging a data center in Los Angeles, California, as a link between the users and some Adobe-internal databases to retrieve project-specific information and to receive community translations. This architecture is not project-specific, but can be re-used for similar projects, independent of their size and scalable to the number of of community participants.

Other Adobe translation pilots that are currently open for user contributions are Adobe Story with 5 existing languages (German, UK English, Spanish, France, Italian), and the Flex SDK with one existing language (Brazilian Portuguese). In the future, the number of products opening up to community translation workflows will grow, and so will the number of languages included in this effort.

A Tool Always Helps: Adobe Translator

AT Dashboard

Since it will be described in a future blog article, here only a brief description of Adobe Translator (AT), Adobe’s own community translation tool.

After logging in with your Adobe ID (you may have to create one first), Adobe Translator presents a dashboard showing all projects in which a product allows users or translators to contribute user interface translations or corrections for a given language. Just select your favorite project and explore the tool’s functionality. The process should be pretty self-explaining, but a brief help can always be accessed from the About menu at the top.

AT Translation Screen

On the translation screen, translators can start contributing right away. Just select a source string and enter a translation in the text field. There may or may not be a translation proposal that AT is providing with the help of machine translation or translation memory (“in the past, this string has been translated as …”). Submit your suggestion and move on to the next string.

Adobe Translator is being developed in an agile fashion in frequent, short “sprints”. In order to leverage the opportunity we had with Business Catalyst, the team’s decision was to expose the application early and listen to user feedback in order to rank its feature development priorities. After the successful pilot with BC, the focus will now be on developing “social”, motivational, and informational features.

More To Come …

For the sake of this article’s brevity, we are not going into further details describing the translation workflow in Adobe Translator: It will be part of a future write-up that will focus on our tool exclusively. In the meantime, if you want to take a test drive using Adobe Translator (maybe your favorite product is already available for community translation), feel free to access and explore it. If you don’t mind sending feedback via email, please use the mechanism in the About menu: We would like to hear from you and are listening.

Rest assured that we continue to work on improvements, especially to make the translation workflow easier and more intuitive. In order to make translating more fun as a group or community effort, we will also do more in “social” areas. We will provide features that will motivate users to contribute (commenting and voting on translations, for example) and those that will allow them to see data about themselves, the communities, and the project(s) they are involved in (for example, through a leader board or project statistics pages).

Again, by all means, please access the application at http://community.translate.adobe.com/translator/ or track our activities on the Adobe Community Translation page at Facebook to read important announcements about Adobe Translator and other community translation efforts.

Dynamic Language Delivery for Adobe’s Mobile Applications

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

Recently, at Adobe’s developer conference Adobe MAX 2011 in Los Angeles, representatives of Adobe Globalization group had the opportunity to present – for the first time publicly – how we are envisioning the deployment of localized resources (texts, user interface strings) to mobile applications in the field.

In their presentation “Dynamic Language Delivery for mobile applications” (here as an Adobe MAX video), Daniel Nay, engineering manager, and Dirk Meyer, product manager, demonstrated how language updates or entirely new languages, can be delivered to applications on mobile devices in a matter of seconds. (In the presentation video, you can find demo sequences at 7:00 and 35:50 on the timeline.)

Localization Of Mobile Applications

Like in all other areas of software creation, the development of mobile applications, too, is increasingly applying “agile development” principles: Short “sprints” are helping to implement specific features in a targeted fashion and to deliver them into the hands of users and customers faster, compared to desktop software products. At the same time, and as a consequence of the new development paradigm, the time between the frequent “pushes” of new product versions become shorter and is often measured only in weeks. As a consequence, an end-user is receiving updated product versions more frequently. Fortunately, their installation only takes a minute or less, and (most important for some!) they can be skipped, if they don’t seem attractive or if there is no time for the update.

Dynamic Language Delivery (DLD): Localization’s answer to agile development

In the world of short development cycles and frequent updates, the differences between versions of a mobile application often consist only of a single feature, or some fixes for software bugs. Accordingly, from a localization perspective, the delta between the localized strings from one version to the next, is often only a small one. There might even be cases, where it is merely a fix for a localized string that constitutes an update. In situations like that, it may look a bit out of proportion to initiate a complete localization cycle for such a small change. Because no matter whether changes are big or small, translators, build engineers and testers, all have to follow a complex workflow with many mutual dependencies before the product finally can reach the app(lication) “stores” or the “markets”. Starting such a powerful machinery, designed to flawlessly localize the most complex desktop applications, for only small changes, and doing so even more frequently than in the “non-agile” past? Again, a bit out of proportion, it seems …

Here now, DLD provides a new way to deploy language resources, like user interface strings or other texts used in an application. And it does so without hindering the fast and agile engineering workflows and without slowing down the subsequent application delivery. Instead, DLD workflows are designed to match agile development cycles, including rapid and frequent deliveries to end-users. DLD enables the testing of improvements and modifications instantly, and allows for approved deliveries to be performed in real-time, be it in staging or production environments.

Principles Of DLD

DLD technology effectively decouples the delivery of the the mobile core application (plus one or more core languages) from the deployment of subsequent language deliveries (like UI string fixes or new languages). It does so by using two completely independent avenues to get those resources to a customer. Here is how …

DLD enablement & deployment

First of all, a DLD-enabled core application takes the usual route and reaches the customer as a fully tested and functional product through being downloaded from a website, “store”, or “market”. DLD-enabled means that an application should integrate a DLD library to perform DLD-related tasks (this integration is very lean and can often be achieved with a single line of code). The other requirement for an application to be prepared for DLD is that it should be architected in a “world-ready” fashion: Strings should be replaceable, variable interface string lengths should be possible through dynamic UI layout capabilities, and more. The good news here: It is already an accepted best practice to write any software – no matter whether it supports DLD or not – in a “world-ready” way so that it supports internationalization features and easy localizability.

If, at a later point in time, new or updated text strings or a new language altogether need to be delivered, a second deployment path through the “localization cloud” will be used, completely independent from the application deployment avenue. The localization deliveries will be held available on servers, queried by the application from time to time for language updates. The frequency of these queries can be set with the help of preferences in the application and, of course, a user should always be able to opt-out of this functionality completely.

Customizing multilingual applications in user-friendly ways

In addition to non-intrusive, instant language updates and the option to add new languages when an application is already in the hands of users, there are more ways how we can see DLD supporting new features of multilingual mobile software.
For example, if an application does not come in the language preferred by the user, DLD functionality can be used to check whether this language might be available from the “localization cloud”. More intelligent applications might actually notice that among its current languages there is none matching the (user-preferred) system language … and trigger an alert to download a “language pack” in the system language, if it is available. Thus, DLD can be used to improve a multilingual user experience, where languages and language updates are available at any time: For those, the need to locate, download or install a complete application bundle does not exist anymore.

Finally, it is important to note (the presentation video shows this), that the language updates are available in the running application right away, without having to restart or perform another type of user action: new resources are loaded in the background and appear seamlessly, once they have been downloaded and integrated.

DLD’s Benefits

In summary, DLD comes with a number of benefits for consumers of mobile applications:

  1. “Instant, real-time” delivery and integration of localization updates and fixes for mobile applications in the field.
  2. Language updates can be configured per user preferences, ranging from completely “transparent” to “fully informed”.
  3. Additional languages desired by a user after an application install, can be added on demand, without having to download and install another complete application package.
  4. Missing languages complementing a local device environment, for example, after switching the system language, can be discovered and installed if the user so desires.

Moreover, software development teams are also among those that save time and effort through DLD technology:

  1. DLD library integration is “minimally invasive” (often, only a single line of code is required).
  2. Leveraging the localization cloud, “world-ready” applications will be able to receive language updates whenever they become available during the development process.
  3. DLD separates application development from localization workflows. By doing so, it removes many process and scheduling dependencies between the two.
  4. Development work can continue until late in the cycle and for as long as the application maintains a state ready to receive strings of multiple languages with different properties.
  5. Development work can continue until overarching milestones are requiring it to get ready for the push live. A user interface does not have to be “frozen” with the arrival of localization resources.
  6. Testing work becomes more efficient and will not be accompanied anymore by repetitive tasks of building and installing the application, before testing it for every language or localization fix. Instead, as long as language fixes are involved, they can be delivered to the application instantly and the testers can verify their integration into the application without delay.

In Short …

DLD is the first workflow allowing for immediate, dynamic, and on-demand localization of an application during post-development states. This is possible through making localized resources available as updates, without the need to re-deploy combined application-language packages as a whole.

Among the advantages of the DLD approach, an almost instant “time-to-market/user” and a much simplified development/localization interplay, are probably the two most valuable ones. From many angles and perspectives, DLD is a fast and resource-saving  way to perform localization deployment for mobile applications running on a variety of devices.

Expect to see it in your favorite Adobe mobile application at some point in the (near?) future.

Invoking ICU from Adobe AIR Applications (Part 2): using Flash Builder 4.6

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

In my previous blog article http://blogs.adobe.com/globalization/invoking-icu-from-adobe-air-applications-2, I demonstrated using the AIR3 ActionScript Native Extensions feature to invoke ICU from an AIR application. I used the AIR developer tools to compile and build various components. In this article, I demonstrate the same using the prerelease version of Adobe Flash Builder 4.6. It is much simpler to do this in Flash Builder avoiding the cumbersome command line.

The prerelease version of Adobe Flash Builder4.6 has a new Flex SDK version 4.5.2, which has AIR3 integrated. Please download the sample files as follows.

You will need the following software to build an ICU extension for AIR platform.

1         Building ICU extension for Adobe AIR

Adobe AIR t native extensions, also known as ‘ane’ or ‘ANE’ files are archived packages. These consist of

  • ActionScript wrapper classes calling into external DLLs
  • The external DLLs
  • XML file describing details of external DLLs

The archived ANE files are used just like SWC libraries in integrating into an AIR application. In other words, ANE file is a library and it has public ActionScript APIs.

Covering all details about the ActionScript extension is too much for this blog article, but I will explain the steps to build this sample and run. Below are the sequential steps and commands.

1.1       Building Windows AIR ICU Extension DLL

1)      The AirIcuExtensionWin folder has the Visual studio solution ‘AirIcuExtension.sln’. Open this in MS VS2010.

2)      The file AIRIcuExtension.cpp has the necessary code needed to interface with Adobe AIR 3. It also has the wrapper routines calling ICU C functions.

3)      This is a DLL project and the build output is AirIcuExtension.dll

1.2       Building ActionScript Library in FB 4.6

1.2.1       Building the ActionScript library

Create a new ActionScript Library project and name it AirIcuExtension. See the downloaded ActionScript FB4.6 library project.

1.2.2       Packaging ActionScript native extension

To package an ANE, you still need to do it in commandline. FB 4.6 does not have a feature yet to generate ANEs in the IDE.

Open the binAirIcuExtension.swc is a zipped archive. Open it using WinRAR or WinZip program and extract the library.swf file in the swc package into the AirIcuExtensionbin folder.

The folder srcresources contains file extension.xml, AirIcuExtension.dll and ICU dlls icudt48.dll, icuuc48.dll, icuio48.dll and icuin48.dll. The file external.xml defines the external library details to AIR runtime.

For simplicity, place the AirIcuExtension.dll, ICU dlls and extension.xml files in AirIcuExtensionbin folder. All these files are packaged into a zipped archive called AiricuExtension.ane using the following command.

C:FB4.6sdksbinadt -package -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target ane AirIcuExtension.ane extension.xml -swc AirIcuExtension.swc -platform Windows-x86 library.swf AirIcuExtension.dll icudt48.dll icuin48.dll icuio48.dll icuuc48.dll

Using Adobe FlashBuilder4.6 or  C:FB4.6sdksbinadt program, one can generate an AIR certificate.

The output is an archive file AirIcuExtension.ane in the AirIcuExtensionbin folder.

1.3       Building the Test program AirIcuExtensionTest.mxml

Now that we built and packaged the native extension package AiricuExtension.ane, we are ready to use this and call ICU services in a test program.

The folder AirIcuExtensionTestsrc contains the test file AirIcuExtensionTest.mxml. The descriptor file AirIcuExtensionTest-app.xml has  the details of native extension.

Flash builder4.6 has a new feature to link Flash applications with ANE files. As you see from the FB4.6 project properties ‘Flex Build Path’ command, there is a new tab for Native Extensions. Using ‘Add ANE’ button, add the AirIcuExtension.ane file present in the AirIcuExtension/bin folder as shown below.

Also see the ‘Flex Building Package’ command in the project properties, there is a new tab for Native Extension. Please make sure that the check box for AiricuExtension is On.

The output swf file AirIcuExtensionTest.swf is placed in the bin-debug folder.

1.4       Building AIR package for executing AirIcuExtensionTest

The final step is to package the above AirIcuExtensionTest .swf and AirIcuExtension.ane files into an AIR executable folder.  We can do this in FB4.6 now instead of using tedious command line.

  • IN FB4.6, select AiricuExtensionProject and execute menu command Project->Export Release Build…
  • In the ensuing dialog, choose Signed native installer radio button. We can only create native installers as we are using OS specific ANE package.
  • In the Native Extensions tab, make sure that the AirIcuExtension.ane checkbox is On.
  • Finish creating the release build after entering the correct AIR certificate credentials.

The output of the above command is an installer AirIcuExtensionTest.exe. By executing it, you can install the test program.

2         Conclusion

The sample illustrated how to invoke ICU from ActionScript. The AIR ICU extension is easy to build using the upcoming AdobeFlash Builder 4.6 release. ANE is a great feature for AIR developers and AIR applications can make use of the platform or ICU provided globalization services.

Adobe Machine Translation Tooling For Moses Presented At MT Summit 13

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

Members of the Adobe MT team were on hand at MT Summit 13 in Xiamen China to present Adobe’s MT achievements and demonstrate next generation tooling for the Moses open source MT platform.  Adobe team members Ray Flournoy, Yu Gong, Christine Duran, and Jeff Rueppel made the journey to attend the 4 day biannual conference.  The conference moves from Europe to North America and this year was hosted in China for the first time.  (Adobe Summer 2011 Intern Yifan Hi took a break from his post doctoral duties and presented his research as well.)

Yu Gong and Jeff Rueppel gave a demonstration of 3 new Adobe tools for streamlining the development of Machine Translation engines using the Moses open source system.

(Adobe’s Scoring Harness Tool)

Adobe employees demonstrated Adobe’s Scoring Harness Tool. (seen above) The scoring harness is one several building blocks Adobe is putting in place to facilitate the automation of MT engine development and deployment.  The scoring Harness automates the quality testing of MT engines using industry recognized standards for engine quality, (Bleu, Nist, Meteor, and TER) and will permit the dynamic testing of new engines against engines already used for production.

Formatting with alternate calendars in Flex

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

Dates can be formatted in various calendars in the Flex SDK. Let’s explore how it works.

Flex SDK lets you format a given date in “alternate calendars” besides the Gregorian calendar. The industry convention refers all non-Gregorian calendars as alternate calendars. To use an alternate calendar, it requires a little bit of care in your Flex application.

Types of calendars

Before we dive into the alternate calendar usages in the Flex SDK, let’s take a brief look at a couple of calen­dars of the world so that you get familiar with what this calendar talk is about. Please be aware, I can only describe the basic usages of some common alternate calendars. There are complexities behind each of the calendars and I may not be explicitly state them. Investigate fur­ther before you actually use them.

Gregorian calendar

This is the calendar most systems provide as the standard. You probably know this calendar already but here are some of the characteristics: There are always twelve months in a year and each month has 28 to 31 days. The numbers of days in each of the months are fixed (30 or 31 days) except for the second month (February), which includes 28 (non-leap years) or 29 days (leap years). The number of days in a year is fixed (365 or 366 days).

Islamic calendar (Hijri calendar)

Islamic calendar is one of the lunar calendars.  There are always twelve months in a year. Each month has ei­ther 29 or 30 days. Beginning of a month is determined by observing the moon phase (Islamic religious calendar). Because of this nature, it is not very possible to predict the dates with the Islamic religious calendar. For the sake of convenience, there is the variant of the calendar, Islamic civil calendar, which determines the dates through some pure mathematical calculation. Islamic civil calendar may not be accurate for religious events. Number of days in a year is 354 or 355 days. Hence, the Islamic calendar year and the Gregorian calendar year are not synchronized.

Japanese calendar

Japanese calendar is very similar with the Gregorian calendar. The difference is the era part and the year. The Gregorian calendar has been using the same era name for the past 2,000 years (AD; Anno Domini). There is also BC (Before Christ) era but BC years are not by supported by pretty much all calendar apps. On the other hand, Japanese calendar era name changes when there is new emperor. Therefore, every ten to a couple of ten years, there are new eras. *1

*1 Before the 1868, the era name changes were more frequent, an era lasted only as low as two years. But just like the BC in Gregorian, there is not much demand to be able to deal with the older eras in today’s calendar applica­tions.

There are much more types of calendars in the world but I hope you got some ideas how calendars can vary.

How to use the alternate calendars in Flex SDK

Now let’s look at the usage of alternate calendars. How do you use calendar other than the Gregorian in the Flex SDK? The an­swer is to use the locale ID.

The locale ID can optionally contain calendar tag. For example:

Locale ID Meaning
ar-SA Arabic used in Saudi Arabia
ar-SA@calendar=islamic Arabic used in Saudi Arabia. Islamic calendar
en-US@calendar=islamic English used in the U.S. Islamic calendar.

When you need to format a date in an alternate calendar, the calendar tag can be appended to the locale ID. Here is an example:

import spark.formatters.DateTimeFormatter;
private function calendarDemo():void
{
    var d:Date = new Date(2011, 9, 15);
    var dtf:DateTimeFormatter = new DateTimeFormatter();
    dtf.dateStyle = "long";
    dtf.timeStyle = "none";
 
    dtf.setStyle("locale", "en-US");
    trace("(1) " + dtf.format(d));
 
    dtf.setStyle("locale", "ar-SA");
    trace("(2) " + dtf.format(d));
 
    dtf.setStyle("locale", "ja-JP");
    trace("(3) " + dtf.format(d));
 
    dtf.setStyle("locale", "en-US@calendar=islamic");
    trace("(4) " + dtf.format(d));
 
    dtf.setStyle("locale", "ar-SA@calendar=islamic");
    trace("(5) " + dtf.format(d));
 
    dtf.setStyle("locale", "en-US@calendar=japanese");
    trace("(6) " + dtf.format(d));
 
    dtf.setStyle("locale", "ja-JP@calendar=japanese");
    trace("(7) " + dtf.format(d));
}

Here is the result you might get.

Please note that the result may vary depending on the run-time platforms.

Limitations you should be aware of

There are couples of limitations in the current Flash Player and Flex SDK for alternate calendar support.

  1. The Date class can handle only Gregorian dates.
  2. The Spark DateTimeFormatter class can format a Date object but parsing feature (translating a formatted Gregorian or non-Gregorian date string into a Date object) is not available. English Gregorian date string can be parsed through the Date class constructor in some degree.
  3. The availability of alternate calendar support and its behavior is platform dependent. Please check the plat­form if the alternate calendar support is important for your application.

If you would like to know more about alternate calendars, the calendar entries on Wikipedia is a good source.

Invoking ICU from Adobe AIR Applications

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

Adobe Flash and AIR are ubiquitous platforms to develop rich internet applications. Flash is used for browser based applications and AIR is used for developing native platform applications. Both platforms have considerable support for globalization. Globalization enablement features like locale aware formatting/parsing, collation, case transforms, localization and multi-lingual text rendering are supported by both these platforms. But some more globalization features like text normalization, transliteration, Unicode character properties, encoding conversions, charset detections, Unicode string utilities etc are still missing in the Adobe AIR and Flash platforms. One of the primary reasons for not adding all these features inside the Adobe runtime platforms is the size of the software.

To overcome the size limitation issue, Adobe AIR and Flash can invoke the services of external dynamic libraries through ActionScript. There are some well known external libraries which have rich globalization support like ICU, GNU glib, Verisign IDN library to name a few. Fortunately the upcoming Adobe AIR 3.0 (now available as Adobe pre-release) has a wonderful feature called ActionScript native extensions, which is about ActionScript programming interface for a native code library like MS Windows DLL, Os X FrameWork, Android JAR or shared library or iOS static library. Please see Adobe AIR3 beta site http://labs.adobe.com/technologies/flashplatformruntimes/air3/ on how to download and take part in the Adobe AIR pre-release. Please make a note that this native extensions feature is available _only_ in Adobe AIR platform, not in the Flash platform.

In this blog, I demonstrate a sample (Download air_icu ) application to invoke ICU from an Adobe AIR application on Windows platform. Readers are reminded that this is only illustration sample software and by no means production quality software. Hence readers must exhibit discretion in using this software as it is. The sample illustrates ICU word breaking, sentence breaking, utf-conversion and Unicode character property verification.

You will need the following software to build an ICU extension for AIR platform.

1         Building ICU extension for Adobe AIR

Adobe AIR t native extensions, also known as ‘ane’ or ‘ANE’ files are archived packages. These consist of

  • ActionScript wrapper classes calling into external DLLs
  • The external DLLs
  • XML file describing details of external DLLs

The archived ANE files are used just like SWC libraries in integrating into an AIR application. In other words, ANE file is a library and it has public ActionScript APIs.

Covering all details about the ActionScript extension is too much for this blog article, but I will explain the steps to build this sample and run. Below are the sequential steps and commands.

1.1       Building Windows AIR ICU Extension DLL

1)      The AirIcuExtensionWin folder has the Visual studio solution ‘AirIcuExtension.sln’. Open this in MS VS2010.

2)      The file AIRIcuExtension.cpp has the necessary code needed to interface with Adobe AIR 3 beta 2. It also has the wrapper routines calling ICU C functions.

3)      This is a DLL project and the build output is AirIcuExtension.dll

1.2       Building ActionScript Library

1)      Build the actionscript library using the below command.

C:Flex4.5.1bincompc.exe -source-path src -include-classes com.adobe.extensions.AirIcuExtension  -external-library-path C:air3_beta2frameworkslibsairairglobal.swc -output binAirIcuExtension.swc

The file AirIcuExtension.as in the folder srccomadobeextensions has the public class AirIcuExtension which calls the ICU routines. In this sample, calling ICU sentence breaker, word breaker, normalizer, utf-conversion and Unicode character property have been illustrated.

1.3       Packaging ActionScript native extension

Open the binAirIcuExtension.swc is a zipped archive. Open it using WinRAR or WinZip program and extract the library.swf file in the swc package into the AirIcuExtension/bin folder.

The folder srcresources contains file extension.xml, AirIcuExtension.dll and ICU dlls icudt48.dll, icuuc48.dll, icuio48.dll and icuin48.dll. The file external.xml defines the external library details to AIR runtime.

For simplicity, place the AirIcuExtension.dll, ICU dlls and extension.xml files in AirIcuExtensionbin folder. All these files are packaged into a zipped archive called AiricuExtension.ane using the following command.

C:air3_beta2binadt -package -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target ane AirIcuExtension.ane extension.xml -swc AirIcuExtension.swc -platform Windows-x86 library.swf AirIcuExtension.dll icudt48.dll icuin48.dll icuio48.dll icuuc48.dll

Using Adobe FlashBuilder4.x or  C:air3_beta2binadt program, one can make an AIR certificate.

The output is an archive file AirIcuExtension.ane in the AirIcuExtension/bin folder.

1.4       Building the Test program AirIcuExtensionTest.mxml

Now that we built and packaged the native extension package AiricuExtension.ane, we are readu to use this and call ICU services in a test program.

The folder AirIcuExtensionTestsrc contains the test file AirIcuExtensionTest.mxml. The descriptor file AirIcuExtensionTest-app.xml has  the details of native extension. Using the mxml compiler, AirIcuExtensionTest.swf is built as follows in AirIcuExtensionTest folder.

C:Flex4.5.1bincompc.exemxmlc +configname=air -external-library-path ..AirIcuExtensionbinAirIcuExtension.ane -output bin-debugAirIcuExtensionTest.swf — srcAirIcuExtensionTest.mxml

The output swf file AirIcuExtensionTest.swf is placed in the bin-debug folder.

1.5       Building AIR package for executing AirIcuExtensionTest

The final step is to package the above AirIcuExtensionTest .swf and AirIcuExtension.ane files into an AIR executable folder.  Execute the following command

C:air3_beta2binadt -package -XnoAneValidate -storetype pkcs12 -storepass <passwd> –keystore <AIR certificate> -tsa none -target bundle AirIcuExtensionTest.air AirIcuExtensionTest-app.xml AirIcuExtensionTest.swf -extdir ….AirIcuExtensionbin

The output of the above command is a folder AirIcuExtensionTest.air. Inside the folder, there is AirIcuExtensionTest.exe. You can execute and see the output.

2         Conclusion

The sample illustrated how to invoke ICU from ActionScript. The AIR ICU extension is easy to build using the publicly available Adobe Flex SDK and AIR3 Beta 2 SDKs. It will be much easier to do all this in the future Adobe Flash Builder IDE using GUI. The advantages of this feature are

  • AIR developers looking to develop international applications for desktop or mobile have the full power of ICU at hand. Many Unicode features, encoding conversions, IDN conversion utilities, string processing, transforms and many more international features can be easily coded.
  • The native ICU extension once built can be used any any developer as it is a library.
  • The Actionscript APIs calling ICU can be coded using the same signatures as ICU C++ API. This eliminates the learning curve.
  • Since ICU is in native code, performance is not compromised.
  • Since it is ICU, developers can expect cross-platform behavior in AIR programs.
  • Since the extension is a AIR library, ICU updates can be easily re-packaged in to the ane file.

In the future once AIR3 is released, a full fledged ICU native extension with proper API definitions will be a great globalization project.

A lightweight auto-complete ActionScript example with a trie

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


Auto-complete functionality is used widely over the internet and mobile apps. A lot of websites and apps try to complete your input as soon as you start typing.  In this post, I would like to introduce a simple ActionScript auto-complete solution by using trie data structure.

A trie is an ordered tree data structure that is used to store an associative array. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Starting from the root node, you can check if a word exists in the trie easily by following pointers corresponding to the letters in the target word. Trie is a well-known data structure in computer science; you can find the detailed information about trie through Wikipedia.

Here is a simple trie implementation in ActionScript:

/**
* An simple data structure to store and look up words.
* @see http://en.wikipedia.org/wiki/Trie for additional details.
*/

public class Trie {
private var _rootKeys:Array;
public function Trie():void {
_rootKeys=[];
}

/**
* Return a list of words which have the given prefix.
*/

public function get(prefix:String):Array {
var results:Array=[];
var letter:String=prefix.substr(0,1);
var root:TrieNode=_rootKeys[letter];
if (root) {
getWordList(prefix, 1, root, results);
}
return results;
}

/**
* Add a word to the object which can be matched as a prefix.
*/

public function add(word:String):void {
var letter:String=word.substr(0,1);
var root:TrieNode=_rootKeys[letter];


if (!root) {
root=createNode(letter);
_rootKeys[letter]=root;
}
insertWord(word, 1, root);
}


private function traverse(root:TrieNode, results:Array, prefix:String):void {
if(root.children) {
for each( var c:TrieNode in root.children ) {
var node:TrieNode = c as TrieNode;
if( node.word ) {
results.push( prefix + node.value);
}
traverse(node, results, prefix+node.value );
}
}
}


private function getWordList(prefix:String,
position:uint,
root:TrieNode,
results:Array):void {
var letter:String=prefix.substr(position,1);
var child:TrieNode=root.children[letter];
if (!letter || !child) {
return;
}


if ( position<(prefix.length-1) ) {
getWordList(prefix, ++position, child, results);
}else {
if (!child.word) {
traverse( child, results, prefix);
}
}

}


private function insertWord(word:String,
position:uint,
root:TrieNode):void {
var letter:String=word.substr(position,1);
if (position==word.length || !letter) {
return;
}


var child:TrieNode=root.children[letter];
if (! child) {
child=createNode(letter);
root.children[letter]=child;
}


if (position==word.length-1) {
child.word=true;
} else {
insertWord(word, ++position, child);
}
}


private function createNode(letter:String):TrieNode {
return new TrieNode(letter,false);
}
}