Posts in Category "English"

Ready For The Community: Adobe Translation Center (ATC)

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

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

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

ATC Landing Page

ATC landing page

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

Not too long ago …

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

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

Product Explorer

Product Explorer

“Community Translation” at Adobe

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

Why does Adobe promote community translation?

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

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

Lightroom Polish

Lightroom Polish project

Why is Adobe building the Adobe Translation Center?

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

Benefits of community translation

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

Feedback and translations through people using our products every day

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

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

Evaluation of more Adobe product languages

ATC Lightroom

ATC Lightroom Page

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

Shipping product languages vs. candidates for new languages

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

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

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

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

Why would users engage in community translation?

Lightroom Translation

Lightroom Translation

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

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

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

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

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

 

Acrobat XI Ships with Improved Middle East Language Support

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

I am pleased to announce that Acrobat XI shipped earlier this month. The Acrobat development team worked hard to provide an improved level of support added for Middle East languages.  Below are details of the additional ME support provided in this release and how you can test drive and use it. We welcome your input, please post any feedback in the comments.

Rob Jaworski, International Program Manager, Acrobat

 

There are four main areas of improvement to Acrobat’s support provided to Acrobat XI: 1) minor editing, 2) Web Capture, 3) improved search functionality, and 4) Hindi/Farsi digits in Annotations.

In order to use these improvements, make sure Arabic and Hebrew language support has been installed.  On Windows 7 and Mac OS 10.x, all language support has been installed by default. You can simply install Arabic and Hebrew keyboard and set the OS format and regional setting as desire.  On Windows XP, if not using the localized Arabic and Hebrew OS version, you may need to install the right-to-left language support from the regional setting control panel in order to have Arabic and Hebrew font and keyboard available.

If you purchase and install the MENA version of Acrobat XI (I.e. English with Arabic support, English with Hebrew support or North African French) on the system, then Acrobat should launch with all the necessary MENA support options already enabled. However, if you purchase Acrobat XI in other application UI languages, the ME support can also be seen or tested by having the necessary options turned on manually.

Here are more details about the improved support for ME languages.

  • Minor Editing– Middle East support has been added to the minor editing feature in Acrobat XI, formerly called the TouchUp Tool. You can newly add or make simple edits to Hebrew and Arabic text on a PDF.  The feature is designed to handle digits, ligature and right-to-left text direction.
    • Before you start adding new ME text or editing existing ME text, make sure the ME support options are enabled.  Go to Edit menu (on Windows) or Acrobat menu (on Mac), select Preferences.  Click ‘Language’ category and verify the section “Editing Text in Middle Eastern Languages” as follows:
      • Main paragraph direction should be Right To Left
      • Ligatures is checked, if needed
      • Hindi Digits is checked, if needed
      • Enable Writing Direction Switching is checked
    • Open a PDF document and open the Tools pane.  Select ‘Add Text’ under Content Editing.  Switch keyboard to Arabic or Hebrew, mouse click on a PDF and start typing text.
    • Open a simple Hebrew or Arabic PDF document.  Open Tools pane.  Select ‘Edit Text & Images’.  Bounding boxes will be on drawn on the editable text. Switch keyboard to Arabic or Hebrew, mouse click at the text to perform a minor edit.
  • Web Capture– Users can use Acrobat XI to convert web pages, HTML files, or plain text files with either Hebrew or Arabic content into PDF documents.  The conversion can be performed via the plug-in buttons available within the supported browsers, i.e. Internet Explorer (Windows Only), Firefox (Windows/Mac) and Chrome (Windows Only).  The text will appear in the correct script and layout, and the output PDF can then be shared for review with other users using the existing Collaboration features.
    • Open an Arabic or Hebrew web page in a supported web browser.  If the Adobe PDF plugin is installed properly, the ‘Convert’ button on the menu bar should be available.   Click Convert to create a PDF from the web page.
    • Alternatively, within Acrobat, select File > Create > PDF from Web Page.  On the Create PDF from Web Page dialog, enter the URL and customize the settings via ‘Settings…’ button.   Specify the file type, language encoding, font setting and page layout.  Click OK to dismiss the setting dialog and click ‘Create’ to convert the web page to PDF documents.
  • Improvement in Search– In the ME version of Acrobat X, the “Ignore Page structure” option under Search preference has to be checked in order to search for ME text on a tagged PDF.  When the option is selected, it not only takes effect to bi-directional scripts but it could produce the irregular drawing for other scripts and could also produce inconsistent search index files, which results in various compatibility problems.  In Acrobat XI, the issue has been addressed by having the necessary implementation that is limited to ME scripts only and having search for ME on a tagged PDF enabled all the time without having to enable any option.
    • Open an ME tagged PDF.  Perform search for ME text using the regular search options available.
  • Hindi/Farsi digits in Annotations– In earlier releases of Acrobat, users are not able to enter Hindi or Farsi digits inside a pop-up note annotation before.  In Acrobat XI, the issue has been addressed to allow an Arabic user to determine the digits used in a pop-up note by using both OS format and current keyboard setting.
    • The digits used in a popup note are determined by both OS format setting and current keyboard.

Arabic Digits: 1, 2, 3, 4, 5, 6, 7, 8, 9

Hindi Digits: ۹ ، ۸ ، ۷، ٦ ، ٥ ، ٤ ، ۳ ، ۲ ، ۱

Farsi Digits:  ۹ ، ۸ ، ۷، ۶ ، ۵ ، ۴ ، ۳ ، ۲ ، ۱

1. Under Arabic format setting (e.g. Arabic (Egypt) or Arabic (Saudi Arabia)):

(On Windows 7, Control Panel > Region and Language > Format = Arabic (<region>), select Additional Settings… and choose a standard digits = either Arabic, Hindi or Farsi)

Scenario (1)

When using English keyboard, then apply Arabic digits (1, 2, 3, 4, 5, 6, 7, 8, 9) in a popup note

Scenario (2)

When using Arabic keyboard, then digits display in a popup note…

A – Follow Standard Digits settings (Arabic, Hindi, Farsi)

B – If Standard Digits NOT set to either Arabic/Hindi/Farsi, then Hindi digits apply

2. Under English format setting (e.g. English (United States)):Arabic digits (1, 2, 3, 4, 5, 6, 7, 8, 9) will always be used no matter what current keyboard or standard digits settings are. Under this environment, a user can have digits displayed in Hindi by, under Region and Language > Additional setting, select ing Standard digits = Hindi and Use native digits = National.

Adobe Type Community Translation

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

Earlier today the Adobe Type team launched a new pilot program for Community Translation. This program is aimed at getting translations for Adobe’s typeface notes and will reward contributors with free fonts. The team will be using the Adobe Translator application to get translations for approximately 400 typeface notes (also referred to as typeface histories). These typeface notes provide users additional information about the typeface and often include information about the history of the typeface. On average, these typeface notes are about 100 words in length.

Continue reading…

GALA Webinar on Localization Project Management

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

Manish Kanwal, International Program Manager at Adobe will be conducting a webinar at GALA (Globalization and Localization Associates), which is the largest non profit standards organization within the language industry. The webinar will present insights into the best practices for managing a complex localization project. Additionally, it will elucidate with a case study of a comprehensively large project with engineering teams spread across the globe including, linguistics, reviewers, legal, supply-chain, marketing, customer-support and many more.

Join this webinar to acclimatize what it takes to project manage and localize in demanding conditions, right from the point the product is envisaged until its public launch. Event details are available here, it will be broadcasted on 26 July 11:00 EDT

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

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

In April, we launched our Globalization Myth series by debunking the myth Globalization = Internationalization = Localization = Translation. This time, we will dismantle another urban legend: “This software product is only for the U.S.”

The problem statement(s)

When a new software product is being designed and implemented, we often hear things like:

  • “Our product is in English only, so we don’t need to worry about localization at all.”
  • “Let’s not worry about localization for now since the initial language requirement is just English.”
  • “Let’s get English out of the door first and we’ll worry about localization later.”
  • “We are now only focused on features, not localization.”

Also, in the statements above, the term “localization” is often interchanged with “globalization” and “internationalization”.

This is somewhat understandable, since the United States has historically been both the top producer and consumer of software products, and its main language, English, has been the world’s lingua franca for over a century.

A reality check

Unfortunately, the above assumptions reflect a mindset that produce a significant negative business impact in the long term. They are false from several perspectives:

  • Very often, software products end up being localized. Can you name a commercially successful software product that is not localized?
  • Even if a product is never localized because of its nature – let’s say it’s a developer tool – or because of little market demand (e.g. some developing markets), its internationalization is likely important for two reasons:
    • The content created with the product might need to be localized. Using  Adobe examples, every day many thousands of customers localize text layers of Photoshop documents, magazine articles created with InDesign, text in Flash animations, websites created with Dreamweaver, and rich internet or mobile application created with Flash Builder, into languages Adobe does not localize their products into.
    • Certain regional markets have specific requirements. Again using Adobe products as examples, specific requirements from our customers in India and the Middle East have motivated us to add Indic support and bidirectional features to InDesign CS6 MENA, even though it’s not localized into Arabic, Hebrew or any Indic language. Also, we have included support for Hanko in Acrobat, to reflect the way documents are signed in East Asia.
  • Internationalization becomes more expensive later on. Remember the car engine analogy we provided in our previous myth article? Thus, it’s critical that product development teams understand the various requirements of internationalization, and the technical, resource and time challenges for meeting them as early as possible, so as to prevent costly architecture changes and code re-writes later on.

The higher cost of delayed internationalization 

Various Total Quality Management studies have demonstrated the benefits of addressing issues at the beginning of a development cycle. The same principles apply to Internationalization. The earlier it gets considered in the product development cycle, the better the overall product quality and the cheaper the development costs will be.

As shown in the graphic below, the cost of addressing internationalization during the Design, Coding and Testing phases are respectively 2, 3 and 4 times more expensive than addressing internationalization during the Requirements phase.

These ratios get even worst after the localization cycle starts (factor of 15x if the product is localized into 15 languages) and the costs of addressing internationalization after a product ships can even become astronomical (30 x).

For example, failure to define and design product requirements in the Requirements and Design phases that meet global customers needs will increase the cost of internationalization in subsequent phases (Coding, Testing, etc.) because of additional time product development teams will spend with:

  • Reporting internationalization-related defects
  • Changing or re-writing areas impacted by internationalization, such as those handling:
    • Dates, times, calendars, numbers, currencies, addresses, measurement units
    • User interface strings, which may require the use of libraries providing string externalization, and changes to all string loading code (e.g. one of Adobe’s teams dedicated 1 developer to work 3 months exclusively on this task)
    • User interface elements such as dialogs and palettes, which may require the conversion from using static UI libraries to dynamic ones.
    • Text processing (input, display, output, sorting, searching), which requires the addition of Unicode support – a low level code which requires major re-testing – and may require the adoption of a new text engine, a major architectural change.
  • In cases where internationalization work is performed many product versions later:
    • Getting developers up-to-speed with impacted code which they might not have originally written, often sifting through legacy code that may not be in use anymore.
    • Re-testing impacted areas of the code that were released in previous versions of the product
    • Project management of focused, ‘one-time’ internationalization efforts
  • Responding to requests and questions from affected customers regarding the lack of support for their language (this has to be explained to every new customer)
  • Managing relationships with third-party solution providers who might have provided the missing internationalization support, and with whom the company might have entered a royalty-sharing agreement with

Also, there might be indirect costs that are associated with:

  • Loss of potential revenue from markets that require internationalization
  • Public exposure of the product’s lack of internationalization when third-party developers fill the gap by marketing their own solutions

Examples of international support in English / non-localized products

The best way to illustrate the importance of international support in English-only products is to show examples of products that have done it.

A calendaring application

In the first example below, an English-language calendaring application offers support for the Thai and Islamic calendars, allowing users from Thailand and 17 Arabic-speaking countries to use it.

 

A tag cloud application and a text editor

It’s very important that any application providing text input or display features support characters from writing systems other than Latin, the one English and most other European languages is based on.

In the next example, a web-based tag cloud application with an English-only user interface allows users to write characters from up to 6 different writing systems representing hundreds of languages, by selecting specific fonts.

The desktop-based text editor below supports close to 20 writing systems, meaning virtually anyone in the world can type with the English version of the product.

A travel website

The following, English-UI travel website offers a good example of how currency, date and time formats are correctly adapted for its German users.

The benefits of global design

In summary, product designers should rarely envision their software products as “U.S. only”. There are many benefits to thinking globally from the start:

  • You will be able to meet any new localization business requirements in much less time and with much less cost. When it comes to localization, in today’s globalized economy, it’s often not a matter of “if”, but a matter of “when”.
  • You will be able to sell your products to customers worldwide, as opposed to those living only in the U.S. or in English-speaking countries, even if your product is not localized (yet).
  • Global architecture design and coding is a one-time investment, and it’s a lot less costly than subsequent re-architecture and re-coding.

Our next globalization myth will be published next month. In the meantime, do you have any good examples of internationalized English-only applications you would like to share? Let us know!

See also

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

Announcing PSE11 and PRE11 Programs for French and German Users

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

Adobe Prerelease Programs are your chance to experience, evaluate and influence upcoming products & technologies from Adobe within a smaller, more focused user environment. Prerelease 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 Prerelease participants at Adobe:

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

A Prerelease 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 Prerelease Opportunities: How to Apply?

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

Following products have been opened up prerelease testing opportunities with French and German builds:

Photoshop Elements 11 for French Users– Sign-up now to participate in the Adobe Photoshop Elements Localized program and preview exciting new functionality! – Apply now

Photoshop Elements 11 for German Users – Sign up to participate in the Adobe Photoshop Elements Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for French Users – Sign up to participate in the Adobe Premiere Elements 11 Localized Program and preview exciting new functionality! – Apply now

 Premiere Elements 11 for German Users – Sign up to participate in the Adobe Premiere Elements 11 Localized 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 Manish Kanwal at mkanwal@adobe.com or Nimra Khan at nikhan@adobe.com.

 

Adobe Flash – Content Creation & Localization Guidelines

Global publishing with Adobe Digital Publishing Suite

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

Digital publishing is a global business

Digital publishing is catching on worldwide, as international catalog, magazine and book publishers are increasingly producing digital versions of their publications, in an growing number of languages.

[tp no_translate=”y”]Adobe Digital Publishing Suite[/tp] (DPS) offers digital publishers with the ability to create multilingual content for the enjoyment of their international readers. This article provides some basic information about the creation of multilingual publications with DPS.

Content localization: region-specific vs language-specific

Region-specific publications carry the main brand (of the magazine, retailer, etc), but are customized to an individual region or country. In the case of magazines, articles are written by local authors, often covering topics and people of local significance.

Language-specific publications translated versions of a single source of content. The articles and authors are the same, the only thing that changes is the language of the content.

Presenting the translated content

With language-specific publications, there are a few different ways to present the translated content, which can impact layout decisions.

The most common type of presentation is single-language, where each language version of the publication is downloadable as a separate application.

Multilingual applications can contain two or more sets of translations of the original content. The translations can be presented through toggling or side-by-side.
With the toggling approach, readers can navigate between content written in different languages by pressing a ‘language switch’.

The article toggling effect provides a smooth user experience, but it does require additional work (i.e. scripting) behind the scenes to make it happen.

The side-by-side approach puts the translations next to each other, typically with different font types, sizes and colors.

Authoring content in different languages

At the core of the DPS workflow is Adobe InDesign, which allows text authoring in many languages. The latest version of the product (CS6) is available in 3 flavors providing distinct levels of language support:

  • InDesign CS 6.0 - Provides core typographical support for a wide range of languages, including those written in certain non-western scripts. It’s localized into English and 16 other European languages.
  • InDesign CS 6.0 ‘CCJK’  – In addition to the core set of typographical features, provides typographical, layout grid and frame grid features for editing East Asian text. It’s localized into Chinese Simplified, Chinese Traditional, Japanese and Korean.
  • InDesign CS 6.0 ‘ME’ - In addition to the core set of typographical features, this version provides full support for bi-directional languages such as Arabic, Hebrew, Farsi, and Urdu. Find out more about the Middle Eastern features here. The ME version is available in English and French user interfaces.

The linguistic capabilities of InDesign are well documented in the product’s help pages, and in articles written by various InDesign experts. Below are some language-specific topics that can assist in the creation of multilingual content in InDesign:

Creating localizable content 

In multilingual digital publishing, a critical aspect of content authoring  – regardless of the language it’s originally written in – is to ensure that it’s localizable, i.e, that it can be easily adapted into (an)other language(s). Below are a few guidelines for creating localizable content in InDesign:

  • Allow for text expansion – Word length varies considerably from one language to another. For example, German and Finnish sentences are on average longer than English. Also, Asian fonts require more vertical space than Latin fonts in order to render certain complex symbols clearly. Thus, it’s important to keep some buffer space around text so that translations can fit it nicely.
  • Apply styles – It’s critical that all text formatting is based on styles, as it ensures consistent formatting across all languages, and it allows for easily changing fonts for languages whose characters are not supported by the font of the source document.
  • Link images - Linked images are much easier to manage during translation
  • Connect text frames – This will ensure text will continue to flow nicely after it’s translated.

More guidelines on content localizability with InDesign will be provided in a future post.

Localizing the content

Localization of InDesign files is typically performed by professional translation agencies, who handle exported IDML (InDesign Markup Language) files in commercial translation management systems (TMS). Ben Cornelius’ article provides a good overview of this process.

Also, some vendors are starting to offer new and innovative ways to localize InDesign content, such as 1i0’s one2edit WYSIWYG tool.

But regardless of the way the content is localized, it’s very important that the work comprehensive: everything, including not only the article text, but also titles, captions, headers, footers, footnotes, and art, should be translated or adapted.

For maximum coverage, even media features, such as audio or video clips, should be subtitled and translated, or dubbed.

Below are some examples of locale-sensitive conventions – dates and times – that need to be adapted for each region.

Publishing the content: DPS multilingual options

The bulk of the process for publishing localized or multilingual content with DPS is not any different than English or single-language content, which is described here.

But, there are a few multilingual options available.

For publications written in bi-directional languages such as Arabic, Farsi, Urdu and Hebrew, readers expect to be able to swipe pages by moving their finger from left to right (ie in the opposite direction than in an English publication), thus right edge binding is necessary. 

To do activate this feature, in the [tp no_translate=”y”]Digital Publishing Suite[/tp], select Right Edge Binding in the [tp no_translate=”y”]Folio Producer[/tp] page.

You can also set this in In InDesign, by selecting the Right Edge Binding  checkbox in the [tp no_translate=”y”]Folio Properties[/tp] dialog.

3eesho is a fine example of a bi-directional publication created with DPS.

Language tagging

Tagging your publication with language information will allow it to be searched by language from e-stores. This can be done during the building of your viewer application, in the [tp no_translate=”y”]Viewer Builder[/tp]:

Localized versions and availability

The [tp no_translate=”y”]Digital Publishing Suite[/tp] user interface is currently localized into English (UK, US), French, German, Italian, Spanish, and Japanese.

DPS Single Edition is available in the U.S., Canada, and Mexico. Availability is expected this year in Australia, Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Latvia, Lithuania, Luxembourg, Malta, New Zealand, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, South Africa Netherlands, Spain, Sweden, Switzerland, and the United Kingdom.

Examples of multilingual publications created with [tp no_translate=”y”]Adobe Digital Publishing Suite[/tp]

Check out many examples of multilingual digital publications created with [tp no_translate=”y”]Adobe Digital Publishing Suite[/tp] by visiting the Digital Publishing gallery.

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 Creative Cloud launched in 8 languages

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

After much anticipation, [tp no_translate=”y”]Adobe Creative Cloud[/tp] has launched!

http://creative.adobe.com

[tp no_translate=”y”]Creative Cloud[/tp] is a membership service which provides online services for file sharing, collaboration, and publishing, as well as access to every Adobe Creative Suite 6 application.

Language availability

The [tp no_translate=”y”]Creative Cloud[/tp] website itself is available in 8 languages: Dutch, English, French, German, Italian, Japanese, Spanish, and Swedish.

The [tp no_translate=”y”]Creative Cloud[/tp] membership is available through the Adobe Store in: Australia, Austria, Belgium, Brazil, Bulgaria, Canada, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Latvia, Lithuania, Luxemburg, Malta, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, UK, and the US.

[tp no_translate=”y”]Creative Cloud[/tp] members can download and install CS6 applications in any language in which the products are available. Unlike owning the traditional licensed version of a Creative Suite product, [tp no_translate=”y”]Creative Cloud[/tp] membership allows you to select from multiple languages. For a complete list of languages in which CS6 applications are available, go here.

To learn more about the [tp no_translate=”y”]Creative Cloud[/tp]

You can learn more about the [tp no_translate=”y”]Creative Cloud[/tp] by watching 10 videos explaining common questions from installing apps, to sharing and moving files, etc. in the [tp no_translate=”y”]Creative Cloud[/tp] YouTube channel (English only) and on Adobe TV (English only).

Also, you can learn more about what’s going on with the [tp no_translate=”y”]Creative Cloud[/tp] by visiting the [tp no_translate=”y”]Creative Cloud[/tp] Team blog (English only).