翻訳で失われた

pierde en la traducción

потерял в переводе

No matter which way you say it, being lost in translation is not just the name of a Hollywood Romi-Com—it can be a nightmare for companies that need to support users in multiple languages.

Handling multiple languages is becoming a requirement for most companies. Globalization is one driver, but more and more, with a growth in the diversity of community languages within most countries, to provide the best and most cost-effective request management to our users, being able to present a user interface in a community language is becoming a necessity.

In Australia—one of the most diverse multi-cultural countries after the United States, most government departments and major corporations provide web-pages and pamphlets in a variety of community languages.

In Europe, while the EU has one currency, it most certainly does not have one language. Multilingual is an essential for business.

So how can make sure that we make sure that our users and business is not ‘Lost in Translation?’

Let’s first look at a what we are really talking about.

Internationalization, multilingualization and localization—Not the same thing!

Wikipedia has this to say about the topic:

The support of multiple languages by computer systems can be considered a continuum between localization (“L10n”), through multilingualization (or “m17n”), to internationalization (“i18n”).

• A localized system has been adapted or converted for use in a particular locale (other than the one it was originally developed for), including the language of the user interface (UI), input, display, and features such as time/date display and currency. Each instance of the system only supports a single locale and there is no explicit support for languages that are not part of that locale (although the character set may coincidentally be usable for other languages).
• Multilingualized software supports multiple languages for display and input, but has a single UI language which cannot be changed after installation of the software. Multi-locale support for other features like date, time, number, and currency formats varies as the system tends towards full internationalization. … In general, a multilingualized system is intended for use in one specific locale, but is capable of handling multilingual content as data.
• An internationalized system is equipped for use in a range of “locales” (or by users of multiple languages), by allowing the co-existence of several languages and character sets for input, display, and UI. In particular, a system may not be considered internationalized in the fullest sense unless the UI language is selectable by the user at runtime. Full internationalization may extend beyond support for multiple languages and orthography to compliance with jurisdiction-specific legislation (in respect of copyright, for instance) and other non-linguistic conventions.

While internationalization is the strategy that ensures that both local, legislative and language requirements are met for all possible environments and users, it is also the most complex and demanding and may not be the correct strategy—in fact it may be excessive in many circumstances.

So how can we decide whether we localize, multi-lingualize or internationalize?

As we deal extensively with user request forms and processes in our practice at Kinetic Data, here is a check-list—not comprehensive, but is a good starting point—for determining what approach we should take expressed with Service Requests in mind.

Localize

• The request form will only be accessed and fulfilled by users in locations that share the same language, information formats, and process requirements
• There are very few—less than 2 or 3—localized versions of a similar request type. More than that will make maintenance of multiple forms a time consuming process
• The process is unique for that location and cannot be adapted for other locations or languages etc.

Multi-lingualize

• The only difference is the display language
• Date/Time, currency etc formats are handled by the application environment
• It is possible to determine or have the user select the language
• The same form and process is to be used by all users in the all locales and languages
• Users need to be able to see the same form displayed in a choice of languages not dependent on locale

Internationalize

• There are differences in the form and processes requirements that are locale dependent
• The maintenance of one set of forms and processes is preferable to the maintenance of multiple forms and processes to cater for locale and language variations
• It is possible to determine or have the user select the locale and language
• The same form and process needs to be used by all users in all locales and languages
• The user may want to select a particular locale and language combination e.g. a user may be in Australia but want to view the request form in Vietnamese for a service that will be delivered in the United States and comply with that locale’s requirements

Kinetic Request has a number of features that make any of the strategies easier to implement.

As well, we have now developed a functionality in Kinetic Request that uses an industry standard Java language translation library to enable one Request Form to be displayed in multiple languages—including non-Roman script languages such as Japanese, Chinese, Arabic, and Hebrew. This functionality goes down to the level of selection field, menu labels and pop-up messages that may be in a Request Form or Catalog Portal.

Kinetic Strategies

Localizing

• Create forms and process for a base locale
• Either use those forms and processes as templates for new forms and processes or use Kurl  to create new forms and processes which have been modified for the next locale. NOTE: localization may not involve a change in the language of the form—for instance a form used in the US  can be deployed in Australia using the same language (ignoring the slight differences in spelling of some words), but the process requirements and field checking will be different for some fields e.g. State is common to both locales but have different different formats.
• Make the localised forms and processes available to each locale through a localized catalog or a specific URLs

           Advantages

• Caters for large differences in form and processes requirements with a reduced effort in creating locale aware forms and processes

Dissadvantages

• Large number locales and languages and processes changes can develop into  maintenance black-hole
• Introducing new locales and languages requires creation and modification of new forms and processes
• Reporting and auditing only on multiple forms and processes
• Lacks flexibility for multiple languages in one locale and visa versa

Multi-lingualization

• Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
• Create the forms and processes in a base language
• Populate the translation tables with the equivalent labels, display values and text strings in each target language
• Either scrape for or let the user select the language

Advantages

• Adding support for new language does not affect the form
• New language requires only editing of the translation table
• Changes in requirements only need to be applied to one form, process and translation table
• Changes or corrections  in translation applied through translation table not the form
• Reporting and auditing only on one form and process

Disadvantages

• Form or translation needs to cater for translation layout differences – size of resulting text or direction (e.g. Right To Left)

Internationalization

• Create forms in a base language
• Leverage Kinetic Request functionality to control fields and display layout – either at the server or client level – to cater for locale difference or requirements
• Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
• Create processes (e.g Kinetic Task trees) that are aware of locale requirements and differences
• Populate the translation table with the equivalent labels, display values and text strings in each target language
• Either scrape for or let the user select the locale and language

Advantages

• Adding support for new language does not affect the form
• New language requires only editing of the translation table
• Changes in requirements only need to be applied to one form, process and translation table
• Changes or corrections  in translation applied through translation table not the form
• Reporting and auditing only on one form and process

Disadvantages

• Form or translation needs to cater for translation layout differences—size of resulting text or direction (e.g. Right To Left)
• More complex initial form and process development

As you can see, Kinetic Request and Kinetic Task give you the ability to deliver the correct solution to your users so they are not ‘Lost in Translation!’