Globalization Myth Series – Myth 1: Software Globalization = Internationalization = Localization = Translation

by Leandro Reis Posted on April 12, 2012

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


Probably the biggest misconception we encounter when talking with some colleagues from outside the Adobe Globalization team is that software “Globalization”, “Internationalization” and  ”Localization” all mean the same thing, and that thing is somehow related to something almost anyone can understand: Translation.

We can’t blame our colleagues for holding such misguided beliefs, as these terms have been used and abused for generations.

It probably doesn’t help that there are also terms in use such as “Culturalization”, “World-Readiness”,  ”Glocalization”, “Transliteration”, “Transcription”, “Localizability”,  and “Japanization”.

The fact that each of these have corresponding abbreviations (e.g. G11n, I18n, L10n, T9n, C13n,  L12y) and also different spellings (“Globalisation”, “Internationalisation”, “Localisation”, etc.) just helps make the whole thing more scary and confusing to civilians.

This article hopes to clarify these differences, and provide a better understanding of the various steps that make up  software globalization.

Clarifying the terminology

We’ll focus our explanations around a few key basic terms that generate the most confusion. One thing to be aware of is that although the meaning of some tasks such as ‘translation’ and ‘localization’ are standard across the industry, some other terms such as ‘globalization’ and ‘internationalization’ are not. The definitions provided here are the predominant ones (which we use at Adobe).

Internationalization (commonly abbreviated as I18n) is an engineering exercise focused on generalizing a product so that it can handle multiple languages, scripts and cultural conventions (currency, sorting rules, number and dates formats…) without the need for redesign. Internationalization, sometimes referred to as world-readiness, can be divided into two sets of activities: enablement and localizability.

Localization (L10N) is the process of adapting a product or service to a particular language, culture, and desired local “look-and-feel”. Translating the product’s user interface is just one step of the localization process. Resizing dialogs, buttons and palette tabs to accommodate longer translated strings is also part of localization.

Translation (T9N) is simply converting the meaning of text in one language into another. In a software product, the content that are translated are user interface, documentation, packaging and marketing collaterals. Most translation work is done by professionals, although in recent years, some companies started exploring the use of ‘community’-translation, and machine-translation.

Globalization (G11N) refers to a broad range of engineering and business development processes necessary to prepare and launch products and company activities globally. The globalization engineering activities are composed of internationalization and localization  while the business development activities focus on product management, financial, marketing and legal aspects.

World-Readiness is an equivalent term to Globalization, but it’s more often used in the context of internationalization.

How do they relate to each other

The simplified diagram below illustrates the relationship between the main globalization-related activities.

In summary, in the context of software:

  • Translation is one part of Localization
  • Internationalization is a pre-requisite of Localization
  • Internationalization and Localization are parts of Globalization
  • Globalization includes many business-related activities outside of the product itself.

A real-life analogy

Still having trouble understanding? Let’s make an analogy to a product everyone is familiar with: an automobile.

The Toyota Corolla is one of the most successful cars of all time. Over 30 million of them have been sold worldwide. But, had its makers not adopted the basic principles of globalization back in the 60s, the Corolla would hardly be known outside Japan today.

So, to achieve such success, Toyota had to:

  • Embrace early on the idea that they wanted to reach markets outside Japan. They set up a world-wide network of in-country marketing, sales and customer support organization. (Globalization)
  • Design and develop a car that could be easily adapted to other geographical markets with minimum cost and effort (Internationalization)
  • Adapt cars to specific geographical markets. For example, for the U.S., Canada and most of Europe, the steering wheel and pedals were easily moved to the left side of the car without structural changes. (Localization)
  • Provide instruction manuals in the language of the market. (Translation)


Example of localization of an automobile user interface

Where the problem lies

So what is the impact of this ‘generalization’ of terminology to the software globalization process?

The main problem is that most product teams look at globalization as a single monolithic process that occurs sometime after design and implementation of the English product, and owned by a single team (the ‘Globalization’ team). This mindset encourages a “throw-over-the-wall” approach which often results in:

  • Additional core engineering and testing effort to resolve critical internationalization issues found late in the schedule
  • Additional localization engineering and testing effort to manually handle localizability issues
  • Higher number of product defects
  • Schedule delays
  • Poorer customer experience

Using the automobile analogy in the previous section, a “throw-over-the-wall” approach would mean that, to adapt a Toyota Corolla designed for Japanese customers to the American market, engineers would need to move the engine or the suspension system in order to move the steering wheel and pedals from the right side to the left side of the car – an expensive and time-consuming operation.


Internationalization helps prevent this

The short story (key takeaways)

  • Globalization, internationalization and localization are related but different activities, performed by different teams at different stages of product development
  • Incorporate Globalization into your thinking as early as possible. Start during design. Ask yourself: which worldwide markets am I targeting in the short term and long term? What do these customers need? If you just think about today’s markets you will ignore globalization.
  • Implement an internationalized product even if you don’t think you will sell outside the U.S. or to non-English-speaking customers, because this decision can easily change and then alterations will be very expensive. If your product is successul in one market, you will most likely have great business opportunities abroad. So, plan for it.
  • Internationalization should be primarily performed by the product’s core engineering team. Do it once, do it right, then hand it over to localization.
  • The localization process will be a lot easier and cheaper if the product is well-internationalized.

The most successful global corporations have instilled Globalization as part of all its employees’ “DNA”. In order for a company or product team to be successful internationally, there must first be a conscious decision from executives and the buy-in from everyone involved in the design and development of a software product to go international. This means that, unless the product and the entire infrastructure surrounding it are not ready to capitalize on the opportunities present in an international market, the global revenue potential of the product will never be fully achieved, or at a prohibitive cost only.

See also

Globalization Myth Series – Myth 2: This product is only for the U.S.

 
Posted in English, Myths, Tutorials | Tagged , , , , , , , , , | 12 Comments

Coming up: Globalization myth series

by Leandro Reis Posted on April 6, 2012

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

Starting this month, we’ll publish a series of articles on  globalization myths.

If you’ve worked in the Globalization industry long enough, you’ve probably heard many of the myths we are going to describe.

If you’re new or from outside the industry, then we hope this series will help set the record straight.

The first article will be published soon. Stay tuned.
Posted in English, General announcements | Tagged , | Leave a comment

Lightroom 4 released

by rlu Posted on March 6, 2012

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

Building on momentum from Lightroom 3, Lightroom 4 brings exciting new features for amateur an pro photographers at new lower price. The release includes 12 languages: English, French, German, Japanese, Spanish, Italian, Swedish, Portuguese, Dutch, Chinese Simplified, Chinese Traditional, and Korean.

All languages are in one installer that can be found from: http://www.adobe.com/products/photoshop-lightroom.html
Posted in English, Product announcements | Leave a comment

Collaborative Translation Helps Adobe Business Catalyst Add New Languages

by Dirk Meyer Posted on November 2, 2011

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.
Posted in Community, Technology | Tagged , , , , , , | 2 Comments

Dynamic Language Delivery for Adobe’s Mobile Applications

by Dirk Meyer Posted on October 21, 2011

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.
Posted in Community, Product announcements, Technology | Tagged , , | 3 Comments

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

by harishs Posted on October 3, 2011

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 bin\AirIcuExtension.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 src\resources 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 AirIcuExtension\bin folder. All these files are packaged into a zipped archive called AiricuExtension.ane using the following command.

C:\FB4.6\sdks\bin\adt -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.6\sdks\bin\adt program, one can generate an AIR certificate.

The output is an archive file AirIcuExtension.ane in the AirIcuExtension\bin 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 AirIcuExtensionTest\src 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.
Posted in English, Libraries, Technology, Tutorials | Tagged , , , , , | Leave a comment

Adobe Machine Translation Tooling For Moses Presented At MT Summit 13

by Jeffrey Rueppel Posted on September 27, 2011

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.
Posted in English, Technology | Tagged , , , , , , | Leave a comment

Announcing Adobe Pre-release Programs for Hebrew users

by Ashish Saxena Posted on September 21, 2011

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

Adobe Pre-release Programs are your chance to experience, evaluate and influence upcoming products & technologies from Adobe within a smaller, more focused user environment. Pre-release Programs facilitate a symbiotic development process allowing Adobe to share products in the development stage to gather early feedback. In the process you get a chance to shape the upcoming products and adapt to the new products faster.

Multiple engagement channels are available to Pre-release participants at Adobe:

  • Access to download Pre-release software/technologies and technical documentation
  • Ability to report bugs & request features for the Pre-release software
  • Access to the Pre-release user forums for sharing ideas directly with Adobe product teams and other like-minded folks of the product’s community
  • Opportunity to participate in various product-related surveys

 

A Pre-release program is an endeavour to engage the real users of the product – YOU – early in the development cycle of the product, to listen and learn from you on how the product is working for you.

Current Pre-release Opportunities: How to Apply?

You may fill in the application forms for expressing your interest to join a products’ Pre-release program at Adobe. The participation will be entirely based on the requirements of the program and the credentials of the participant.

Following products plan to open-up pre-release testing opportunities with Middle East English – Arabic Enabled, Middle East English – Hebrew Enabled and North African French builds:

Adobe InDesign – Sign-up now to participate in the Adobe InDesign ME pre-release program and preview exciting new functionality! – Apply now

Adobe Illustrator – Sign up to participate in the Adobe Illustrator ME Program and preview exciting new functionality! – Apply now

Adobe Photoshop – Sign up to participate in the Adobe Photoshop ME Program and preview exciting new functionality! – Apply now

We look forward to your participation in this pre-release program. In case of any issues of if you need more information, please feel free to contact us at menaprerelease@adobe.com

On behalf of – Ahmed Gaballah, Ashish Saxena, Avinash S. Kotwal, Iouri Tchernoousko
Posted in English, General announcements | Tagged , , , | Leave a comment