The app economy is growing at a tremendous speed. There’s been a 60% growth in the number of app downloads globally, consumer spending has more than doubled, and time spent in apps spiked by 30%; to the point where each user spends about 43 days per year using apps, reports App Annie.
While a large chunk of the mobile phone app builders and users belong to English speaking countries such as the United States, an ever-larger percentage comprises of various non-English speaking European countries, and south-east Asian countries. Users from countries like Brazil, China, and India download up to 11 – 12 apps at an average per day, as per TechCrunch reports. This is a huge rise in numbers from a few years back and thus this is a market that is ripe for the taking.
Apps that have a version available in multiple languages perform far better than apps that don’t. And this process is not simply restricted to the language within the app. According to AppAnnie, the top 60% of iPhone apps used in Korea are not only available in Korean, but also have Korean names. Almost 50% of the top apps used in China are apps based in native languages, states the same source. These numbers are reason enough to get yourself on board the localization train, whether you are a developer or service provider.
Below chart confirms benefits a business gets from app localization –
Benefits of app localization
Targeting local markets with personalized products have always been a great marketing strategy, and app localization is definitely a part of the same approach. Below are some of the benefits it can provide to a business, or rather to the mobile phone app.
Wider Reach – Globally, 72% of the people who use mobile phone apps are not English speakers.
Customer satisfaction – 56.2% of consumers feel that obtaining information in their own language is much more important than price.
Untapped market – While your business idea may not flourish since there is a high level of competition in your local market, you can always target your business efforts to another linguistic market with the help of localization.
Revenue margins – More than 50% of the countries who download the most mobile apps every year are non-English speaking countries and being able to sell to them will shoot up your revenue margins like no other.
Localization is currently the strongest force of marketing when it comes to mobile apps and if you are a developer or service provider, it is absolutely necessary for you to integrate these aspects in to your app.
So, are companies really making success using properly employed localization strategies? A recent study by Distomo revealed that it can result in 128% more downloads and 26% increase in revenue within a week!
Expect to see more data insights in the next blog…
With increasing access to the web, online content has become the ‘first’ customer interaction point for most brands. As businesses go global, the end user expects the brands to host their content specific to their region/preferred language. To facilitate and support the requirement for global presence for businesses, Experience Manager has built tools for content translation. Using out-of-the-box multilingual features, customers can translate
to any locale.
In-built functionality for Multilingual support in Experience Manager includes:
The user would want to update the translated content if the source content has changed. Smart translation feature detects which source pages/assets have been updated, deleted or created. Only these pages/assets are send for translation, thereby reducing the cost of re-translating entire site.
These content types can be extracted from a page where they are referenced. Hence, user doesn’t need to know the location of the referenced content.
Beyond Experience Manager features, an ecosystem is built around multilingual support.
Translation Partner connectors
To support content translation there needs to be a translation connector. Adobe Exchange (https://experiencecloud.adobeexchange.com/ ) host 19 translation connectors to choose from, depending on partner vendors or translation method. By default, Experience Manager ships with Microsoft Connector which supported Machine Translation.
With Adobe After Effects CC you can now create text layers containing Indic languages and animate them with all its cool features. This capability is provisioned via the Adobe World Ready Composer, which also powers the likes of Premiere Pro, Photoshop and InDesign. The Indian languages supported are Hindi, Marathi, Gujarati, Tamil, Punjabi, Bengali, Telugu, Oriya, Malayalam, and Kannada. In addition to this, After Effects also supports Arabic and Hebrew in the RTL type setting.
This capability also enables cross product workflows between After Effects and Premiere Pro, both of which support these languages.
Setting Indic Preferences.
To use After Effects CC to create a text layer, all that you need to do is to enable the Adobe World Ready Composer. This text engine switch is a necessary step to make After Effects start handling complex Indic scripts.
1. Go to Preferences>Type
2. Select ‘South Asian and Middle Eastern’ in ‘Text Engine’
3. Select ‘Indic’ in ‘Languages Selection’
…and you are all set! Create a new text layer and start using your Indic fonts and keyboards to create text effects on your videos.
In addition to that, video animators will be able to do a lot more than before with After Effects including:
– Indic text will support all the styling capabilities from the character and paragraph panels.
– The 3D animation feature set, type features, and animation presets
– Track Indic texts to the motion of the video
– Export composition for Adobe premier Pro project
– Export as Motion Graphics Template
After Effects will now support all Indic Unicode fonts. In addition to that Adobe also offers beautiful looking fonts in most of these languages, and you can access these Adobe fonts from Typekit using the Creative Cloud Desktop app.
See what’s new in the latest release for Adobe Creative Cloud video and audio tools, including Premiere Pro, After Effects, Audition, Character Animator, and Adobe Stock here.
Product development has evolved dramatically in the last couple of decades. Engineers these days are a lot more internationalization-savvy when it comes to developing and testing global products. The advancement in tools and technologies is also making the process of handling input methods, date/time formats, global characters, and other such aspects, integral to a world-ready product development process. Adobe too has a state-of-the art globalization framework and a dedicated globalization team to help product teams meet diverse regional and cultural needs with ease.
Recently, the Adobe Japan engineering team – in their quest to add more value to regional customers – proposed extending Adobe Stock’s capability into Microsoft® PowerPoint®. The idea was simple; integrate Adobe® Stock®, which offers millions of images, graphics, templates, and other assets, with MS PowerPoint, which is one of the most popular products used for creating great presentations. For the Japan market, this integration meant a perfect tool for increasing the visibility of Adobe Stock, a relatively new product in the Japan market. However, we realized that the idea was compelling, not just for the Japan market, but for markets across the globe.
The Adobe Japan team collaborated with cross-functional teams within the organization, including the Stock product team, to vet the idea. A proof-of-concept was built, as this capability was new for Stock too, and presented for validation to key stakeholders in engineering and other business functions.
After the go-ahead, a cross-campus team was set up to implement the idea. Along with the Stock team, the India-based Globalization Technologies team contributed to make the integration happen.
A key learning from this project was that features requested by the regional markets need not be region-specific. Conceptualizing a feature that is universally relevant has a greater chance of being prioritized in the product development process.
The Stock-PowerPoint integration is a true example of geo-driven global feature development. Although a feature conceptualized for the Japan market, it became relevant to users world-wide.
For more information about the plugin, please visit the Stock-Powerpoint HelpX site.
Together we’ve successfully created a support network where we can share best practices and challenges using AEM and push each other further in our practice. As a keeper of this space of AEM community, I was very impressed by the commitment and enthusiasm that all of you have shown at the event. There were 43 of us from Singapore, Hong Kong, Malaysia, Australia, India and the United States in the room and 5 members joined us on Adobe Connect from the US.
On behalf of the group, I would like to thank you to all of our speakers, David, Angie, Alan and Eli for their leadership to be in service to the AEM community – so much thought, effort and time went in to the presentation that we have received and we are very grateful for that. Special thanks to David for flying in from California just to champion the first event in APAC, and Eli for generously putting together a special SEO session with such a short notice. Lastly many thanks to Therese Harris at Clay Tablet for funding some of the activities. All of you have embodied the true community spirit!
Until we see each other next time, let’s continue the conversations at our Linkedin group.
It’s a known fact that Apple’s two-third of the business comes out of outside United States regions and no company would undermine the value of the business which it is getting from international markets. Keeping that in mind and addressing this aspect even further, Apple has made some latest advancements in the Internationalization support of its mobile operating system iOS 9.
Here are the top 7 features which made the cut to the latest iteration of the mobile operating system iOS9:
Support for RTL – Right to Left Languages
One of the most notable feature of iOS 9 in regard to internationalization was the addition of support for right to left (RTL) languages like Arabic & Hebrew. Using the UIKit framework provided by Apple in its Xcode IDE, you can mirror your icons, text, animations in a jiffy. Furthermore, all those native interactions related to Apple’s OS would also get mirrored like while operating your iPhones & iPads you will swipe the screen from right to left to unlock your screen, swiping of home screens from right to left, navigate back in safari from the right and forward from the left et al.
Apple has gauged the growing demand for its mobile & tablet devices in India and therefore, it extended its keyboard support for some more Indian languages like Punjabi, Gujarati and Telugu. Evidently, the intent here is to capitalize the Indian growing smartphone market by offering some user-friendly features.
Now, Autocorrect in ‘QuickType Keyboard’ (For Japanese and Chinese users)
Apple has made the life easy of all those folks whose native language is Japanese and Chinese by offering them AutoCorrect feature in the QuickType keyboard. They can now simply select the text using the multi-touch feature of the new redesigned keyboard and then can apply the Auto correct feature to straight things up.
This feature will ease up the task of the users who find it challenging to type commonly used sentences a number of times using iPhone keyboard.
Transliteration for Hindi Keyboard
And that’s not all, Apple has also given a treat to its Indian customers by adding transliteration support for Hindi keyboard in which all those users who was not comfortable enough to type in Hindi directly, can now type in English characters and the powerful transliteration system will offer you suggestions by converting them to Hindi. For more detailed information about the last two features, have a sneak peek at the ‘Quick Type’ section at http://www.apple.com/in/ios/whats-new/.
More Keyboards (for French, German, Spanish etc.)
Apart from the Indian languages, the tech giant has also added new keyboards for some other regions like French (Belgium), German (Austria) and Spanish (Mexico).
Switch between number systems for cosmopolitan Dubai
Another important update to users living in UAE is giving them the freedom to switch between number systems. They can choose which number system (Arabic, Hindi) they want to use – so you can use your device in the way that feels most natural to you.
Predictive Input for Fr, De and some more languages
One more addition to the plate is the addition of predictive input for French (Belgium), German (Austria), Korean, Russian, Spanish (Mexico), and Turkish.
After all these updates to the keyboard, dictation and predictive typing system of the iOS, the current support provided by Apple for the world of languages in its mobile devices is demonstrated in the below snippets:
English (Australia, Canada, UK, U.S.), Chinese (Simplified, Traditional, Traditional Hong Kong), French (Canada, France), German, Italian, Japanese, Korean, Spanish (Mexico, Spain), Arabic, Catalan, Croatian, Cz_ech, Danish, Dutch, Finnish, Greek, Hebrew, Hindi, Hungarian, Indonesian, Malay, Norwegian, Polish, Portuguese (Brazil, Portugal), Romanian, Russian, Slovak, Swedish, Thai, Turkish, Ukrainian, Vietnamese
Quick Type keyboard support:
English (Australia, Canada, India, Singapore, UK, U.S.), Chinese -Simplified (Handwriting, Pinyin, Stroke), Chinese – Traditional (Cangjie, Handwriting, Pinyin, Stroke, Sucheng, Zhuyin), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian, Japanese (Kana, Romaji), Korean, Spanish (Mexico, Spain), Arabic, Bengali, Bulgarian, Catalan, Cherokee, Croatian, Czech, Danish, Dutch, Emoji, Estonian, Filipino, Finnish, Flemish, Greek, Gujarati, Hawaiian, Hebrew, Hindi (Devanagari, Transliteration), Hinglish, Hungarian, Icelandic, Indonesian, Latvian, Lithuanian, Macedonian, Malay, Marathi, Norwegian, Polish, Portuguese (Brazil, Portugal), Punjabi, Romanian, Russian, Serbian (Cyrillic, Latin), Slovak, Slovenian, Swedish, Tamil, Telugu, Thai, Turkish, Ukrainian, Urdu, Vietnamese
English (Australia, Canada, India, Ireland, New Zealand, Philippines, Singapore, South Africa, UK, U.S.), Spanish (Chile, Colombia, Mexico, Spain, U.S.), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian (Italy, Switzerland), Japanese, Korean, Mandarin (Mainland China, Taiwan), Cantonese (Hong Kong), Arabic, Catalan, Croatian, Czech, Danish, Dutch (Belgium, Netherlands), Finnish, Greek, Hebrew, Hungarian, Indonesian, Malaysian, Norwegian, Polish, Portuguese (Brazil, Portugal), Romanian, Russian, Slovakian, Swedish, Turkish, Thai, Ukrainian, Vietnamese
English (Australia, Canada, Denmark, India, New Zealand, Singapore, UK, U.S.), Spanish (Mexico, Spain, U.S.), French (Belgium, Canada, France, Switzerland), German (Austria, Germany, Switzerland), Italian (Italy, Switzerland), Japanese, Korean, Mandarin (Mainland China, Taiwan), Cantonese (Hong Kong), Swedish (Sweden), Dutch (Belgium, Netherlands), Norwegian (Norway), Russian (Russia), Turkish (Turkey), Thai (Thailand), Portuguese (Brazil)
Now with the news coming in that Siri would be localized into many more languages and would operate without an Internet connection when iPad Air 3 comes to the market, it certainly acknowledges the fact that Apple has a vision for its virtual assistant to break down all the language barriers. Hoping that Siri would be available in Hindi too, it would be a remarkable experience to hear some Santa Banta jokes from the smart voice-powered Apple’s assistant.
To conclude I would say, Apple has gone to the right way to push out features which may not be so relevant to announce during the unveiling of the OS at WWDC but are undoubtedly needed to support the international markets.
If you made this far, thanks for reading. Please let us know your feedback, comments about this article and if you know something which I have missed here, kindly drop in your comments and I will try my best to respond and take this conversation forward.
If you want me to write on a particular topic then do let me know.
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.
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
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.
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.
Adobe Devanagri was introduced in CS6 timeframe, and has now been extended to include the Marathi script as well.
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.
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.
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.
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.