The document discusses localization and provides best practices for localizing software and content. It explains why localization is important for reaching global markets and what could go wrong if not done properly. It emphasizes separating content from code and opening the "black box" of localization by using computer-assisted translation tools, translation memory, terminology databases, and quality assurance processes. The document also covers localization considerations, testing, and tools to support agile and continuous delivery of localized content.
2. PLAN OF TALK
Why Localize?
What could go wrong?
First Principle of Localization
Opening The Black Box
Making Localization Work
Tools for Agile and Continuous Delivery
Discussion
4. Localization is the only way to
reach global markets
• Seeking increased foreign markets
share
• Multilingual is a requirement, not a
nice to have
o Compliance, regulations,
mandates
o User-generated content
o Customer satisfaction and
experience
5. QUICK FACTS
•2012 Ditmo study: downloads for apps in foreign
markets increased by 128 when translated into
target language
•2014 Common Sense Advisory Study finds 75% of
global consumers would choose native targeted app
over similar non-targeted; more than half would
prefer poorly translated app to non-native
•2016, Asia-Pacific region surpasses North and South
America as leading rev generator in app sales
•John Yunker @ Global Design: Do businesses in the
US ask "what's the return on investment for creating
a website for my business?"
6. FIRST PRINCIPLE OF LOCALIZATION
• Separate Content from Code
• Benefit 1: protects code from
corruption
• Benefit 2: opens the pool of
human translation talent
7. WHAT COULD GO WRONG?
• Poor quality translation (missed context)
• Unexpected Costs (employee time suck)
• Missed deadlines
• Mangled code
• You build it, but they don’t come (SEO)
10. DEFINITIONS
Translation: replacing text in one language with
text of equivalent meaning in another language.
Localization (l10n) : includes all of the changes
needed to adapt content for a particular market, to
take into account things like local time, date, and
currency formats; cultural preferences about
content; UI and design choices.
Internationalization (i18n): Preparing software
and websites to ensure a smooth and error-free
localization process.
11. WHAT ARE THE CORE
TECHNOLOGIES THAT
PROFESSIONAL TRANSLATORS
USE?•The CAT Tool
•Translation Memory
•Term Base
•QA
•Pseudo Translation
13. LEADING CAT TOOLS
• Desktop vs. Cloud
• SDL Studio, MemoQ,
SmartCAT, Wordfast
14. CAT tools unify the translator working environment
by hiding the file format differences and hiding
formatting choices, tags, and other non-
translatable script
15. TRANSLATION MEMORY (TM)
• Stores prior translations by the
“segment”
• Available to translator when
processing translation
• 100%, context, fuzzy matches
16. TRANSLATION MEMORY
Pros
• Increases efficiency
• Reduces costs
• Ensures consistency
• Speeds translation
“Cons” (no free lunch)
• TMs can remember
mistakes in translation
• TMs require maintenance
to remain useful
• Some argue they can
reduce translator focus on
best translation
18. TERM BASE
• Ensures consistent
terminology
• Stores by single
words and short
phrases
•Available to
translators in process
•Very useful in final
stage QA
•Helpful for accurate
translation of UI
23. QA
Computer algorithms check for
patterns that suggest error:
• Inconsistency in source
• Numeric mismatch
• Empty segment
• Missing tags
• Source and Target identical
24.
25. PSEUDO TRANSLATION
• Produces generated, fake translation for testing purposes
• Confirm character encoding OK
• See how UI does with text expansion, right to left
• Confirm all translatable content has been captured
• Prototyping workflow
30. AUTOMATION?
• How often do you release content
updates?
• Are you on an agile or continuous
delivery cycle?
• If updates occur more than a few
times a year, strongly consider
adopting a localization platform so
that content changes are captured
and pushed to translation teams
automatically.
• (we’ll discuss localization platforms
in a little more detail, later)
31. CMS
• How well i18n-ized?
• Wordpress, Drupal, Joomla, Any
CMS, Squarespace, Wix
• General rule of thumb: Platforms
that require less tech savvy generally
present higher problems for
localization
• Has to be responsive. Most foreign
markets more mobile than US.
• Needs to export translatable
content in some form of XML
• Note: We’ll talk about dev
32. ENCODING
• Most modern CMS support
Unicode (UTF-8), but make
sure, and make sure encoding
us maintained throughout the
cycle of localization
33. TEXT: BEST PRACTICES
• Leave room for text expansion
•Keep translatable text together in
resource files
• Don’t hard code international date,
time, measurement
• Be careful with use of concatenated
and dynamic text, as grammar and
word order rules changes across
locales
34. CONTENT AND DESIGN
• Simple and clear language in source
• One term, one meaning
• Avoid slang, references to local culture (unless
necessary)
• Transcreation for marketing content and keywords
38. SEO/ ASO
• Be careful that your localization
choices don’t end up crippling
your international SEO
• Pay attention to how information
architecture choices can impact
performance (ccTLD, sub-domain,
sub-directory)
• Follow latest practices regarding
meta information ( hreflang,
region-specific language locales…)
• Consider transcreation for apps
descriptions and keywords
39. TESTING
• As good and useful as some in-
context editing can be, there is no
substitute from having someone
actually use and experience the
localized software
• pre-live testing should always be
considered in parallel with a pseudo
translation/localization process before
the translation stage has completed
• pre-live testing should not be
catching issues that pseudo translation
could have caught
43. SMARTLING
Key Features Drawbacks
• It’ll cost you• Good at capturing
translatable content with
little developer intervention
• Global CDN (fast content
delivery)
• Relatively Strong TM
Management
• Excellent SEO tools
• Tailored connectors to
different CMS
44. LOCALIZEJS
Key Features Drawbacks
• Little or no SEO
• Poor quality control
• Limited TM management
• Little tech capability
required
• “Push-button”
human translation
• Inexpensive
45. PHRASEAPP
Key Features Drawbacks
• Limited translation memory
management
• Buggy file conversions
• Incomplete Locale Selectors
• Largely agnostic to file
type
• Github support
• Relatively inexpensive
• Translation Progress
Dashboard
46. ALCHEMY CATALYST
Key Features Drawbacks
• Requires employee training
• Needs in-house resources;
local deployment
• Windows-centric; no iOS
support
• A little crusty
• Supports all aspects
of localization cycle,
translation,
engineering, testing
and project mgmt.
• Advanced translation
memory
• Long-time market
leader
47. WHAT TO CONSIDER
• Development Environment
• Budget
• Project management resources
• Level of automation needed
• SEO Expectations
• Future: enabling spoken interaction in multiple
languages
48. SO….
• Opening the localization black box helps to
bridge gaps between technologists, linguists
and PMs.
• The sooner developers develop good i18n
habits, the smoother the l10n process can go.
49. SHARE YOUR EXPERIENCES
• How often do you release content updates?
• What is the scope and cadence of releases?
• Are you aiming for “sim-ship”? (Simultaneous shipment across all
markets incl. foreign)
• Think about your localization goals: agile or continuous delivery?
• Is it acceptable to distribute localized versions on a schedule other than
the US releases?
• How do you ensure that source/English content is prepped for
translation? How much is context needed?
• How do you budget for localization expenses? Is it tied to a customer’s
order or market research? First-to-market?
• What does your localization team look like? Who is responsible for what?
51. FILE FORMAT STANDARDS
• minimum bar for
localization talent pool:
XLIFF, TMX
• TBX, PO
• Issues with standard
formats: variations in
implementation across
CAT tools can cause
issues
Editor's Notes
Two decades in cross-cultural digital publishing
Worked as developer, team lead, consultant for Chinese Internet companies
Witness dawn of Internet age in China in mid 90s
PhD in Communication, with focus on International Communication
2 years as Localization Project Manager at MTM LinguaSoft
Talk about localization as a process
Tell HMI story
Need to create global content value chain
Seeking increased foreign markets share
Multilingual is a requirement, not a nice to have
Compliance, regulations, mandates
User-generated content
Customer satisfaction and experience
Needs to move from afterthought to forethought
Improve ROI and project success
Old ways negatively impact agility, not responsive
App annie
A 2012 study by Distimo, an application store analytics company, showed that downloads for apps in foreign markets increased by an average of 128 per cent when the app was translated into their language. This boost in downloads occurred within 1 week of their launch. Native language availability affected not only downloads but revenue. In China, for example, more than 80% of all generated app revenue was from apps available in the local language. The same was true for Japan, while more than 70% of revenue generating apps in Korea were in the local language.
A 2014 study by Common Sense Advisory (“Can’t Read, Won’t Buy) found that 75% of 3000 global consumers surveyed indicated that, when faced with a choice between two similar products or services, they would choose the one offered in their native language. And more than half said they would prefer partial or poor quality translation to a product without support in their native language.
In 2016, the Asia-Pacific region surpassed North and South America as the leading revenue generator in app sales. China alone counted for more than 50% of the sales growth for iOS apps and, according to global market research firm Newzoom, will continue growing at a CAGR of more than 17% through 2020.
John Yunker, at Global by Design, makes a strong case that the question is not always asked for the right reasons. Do businesses in the US ask "what's the return on investment for creating a website for my business?" No. The question isn't asked because a website is necessary for doing business in the US. If you want to sell your products or service globally, you need to translate your website.
Corallaries
use resource files for translatable strings
ensure CMS supports some level of XML export
use UTF-8 (or other variants, when necessary)
Communicate with LSP about translatable strings
for unusla files, LSP can write regular expressions to extract text and protect code
(Show visual explaining how the pool for translation talent shrinks as demands for specific tech aptitudes grows)
*By separating code from text, we protect the source code and ensure the widest possible pool of translation talent (they don’t need to be code savvy).
*Separating code from text can be straightforward or it can take time to sort out. How we deal with non-standard file formats.
[screen shots that show cleaned up code, use of XML, regular expressions]
Talk about ideal scenarios/ gold standard for client side:
updates in English code discovered and automatically flow into target language software without customer thought or effort
flexibility in workflow choice
Use cisco-eagle, bliss logic, connectify for demo?
http://daily.unitedlanguagegroup.com/stories/editorials/two-localization-fails-apple-starbucks
SDL International, conducted a survey, which revealed the negative impact inaccurate translation and localization can have on international companies. It showed that an astounding 80% of the global companies surveyed experienced lost revenue due to translation and localization issues. A further 40% of the respondents stated they have had to delay product launches because of mistranslations, and 7% claimed they had received fines by local governments for non-compliance as a result of translation errors.
Example NextDocs
Translation is part of Localization
Available as features of larger programs, platforms used by professional translators.
These are the capacities that we expect of virtually all translators we use (unless domain and/or language are narrow)
The CAT tool is still the central metaphor for the translators active translating workspace. It presents the “object” to be translated broken into segments, which can be saved and reused, and which can trigger other information resources helpful in the active translation process, such as dictionary defintions of more “difficult” words, or indications that a given term has a pre-defined translation (term base)
Meta data for memory management
Ibid
https://docs.oracle.com/database/121/NLSPG/ch2charset.htm#NLSPG171
Tech
Choose a platform with solid internationalization (XML export?)
Use UTF-8
Know where the translatable strings are, keep together as much as possible
UI/UX
Have room in UI for text expansion
Consider cultural consulting for best UX [examples?]
Color choices, hand gestures, flags.…
Content
Use simple and clear language in source
One term, one meaning
Avoid slang, references to culture that may not be understood (SuperBowl….)
Neutral (or flexible) iconography and imagery
Context! Provide reference materials, guidance for translator
https://phraseapp.com/blog/posts/10-common-mistakes-in-software-localization/
ou are ready to release the new app, the software localization code is bug-free and the new design is crisp. But does it work in languages other than English?
If your answer is “no” you might find yourself reworking the whole app to support other languages, because you did not care about this when writing your code.
Internationalization, or i18n if you want to be cool, is the process of developing a piece of software or app so that it can easily be translated and localized into other languages – and it’s much easier if you do it right from the beginning.
If you don’t want to spend months fixing software localization bugs, you should consider these 10 common pitfalls that prevent applications from being properly translated and localized. This article covers each of these issues, explaining what to avoid and providing some key software localization best practices.
1. Embedding Text Directly To The Code
Embedding text directly to the code will slow down the software localization process tremendously, as the translator needs to actually read the code to determine which segments need translation and which ones do not. Also, it makes localization more costly than necessary and the consistency of the translation will be difficult if not impossible to maintain.
Use Separate Resource Files
Those strings include titles, product names, error messages and any other text that users might see when using your app/software. You should get all of these user-visible strings out of your code and place them into resource files, giving each string a unique name (think of it as a identifier or key) and specifying different translation values for that string.
These resource files will be loaded by a library that uses a combination of language and country (also known as the “Locale”) to identify the right string.
Once you’ve placed your strings in external resource files, you can send these files to your translation vendor and get back translated files for each locale that your application is going to support.
Take care when choosing key IDs for your strings. The IDs should always describe the string’s role in the interface (titel, button label, etc.). Also, make sure that you are not duplicating an existing ID when adding new strings
There are various file formats that make suitable resource files. Popular choices are JSON, XML, gettext or YAML.
Depending on the programming language or framework you are using there usually will be a de-facto standard format.
In Python, the GNU gettext system is a popular choice. A .po resource file containing the translatable strings is created for each locale:
1
2
3
4
5
6
# ./locales/en_US/LC_MESSAGES/messages.po
msgid "button_order"
msgstr "Order Now"
msgid "login_message"
msgstr "Welcome back!"
1
2
3
4
5
6
# ./locales/de_DE/LC_MESSAGES/messages.po
msgid "button_order"
msgstr "Jetzt bestellen"
msgid "login_message"
msgstr "Willkommen zurück!""
And the gettext function is used to get the appropriate translation:
1
2
3
4
5
6
7
import gettext
de_DE = gettext.translation('messages', localedir='locales', languages=['de_DE'])
de_DE.install()
print(gettext("login_message"))
# Willkommen zurück!
print(gettext("button_order"))
# Jetzt bestellen
2. Pixel Based Layouts / UI Requires Editing After Translation
Don’t assume every language is as concise as English.
English text is often very compact compared to other languages – like German or Finnish, for example – and translations can be vary considerably in length and density.
If you don’t prepare for this and there isn’t enough space, your strings might overlap other controls and the interface will require editing after translation.
Design For +50% And Give Strings Room To Grow And Shrink
The interface must be able to adjust size to accommodate the length of translations provided at runtime.
You can solve this problem by leaving extra space after each label for the string to grow. However, by doing so the labels and controls might appear pretty far apart from each other in compact languages. Some developers give their labels room to grow and shrink by aligning them to the right or by placing them above the controls.
You can also use layout managers, that understand how locale affects a UI and manage the pixel positioning of widgets for you at runtime, so your interface will adjust properly.
Another way to solve this issue is by storing the dimensions for a label in the locale resource file.
3. Specifying A Language, But Not A Country
Sometimes a language differs depending on the country in which it is spoken like en-GB and en-US, because different regions may speak and spell a shared languages with nuanced differences. Specifying a language, but not a country code can make localization difficult..
Always Use A Full Locale
Be as precise as possible. and always use a full locale property instead of just a language, which contains both the language and the country code where it is spoken, such as fr-FR or en-GB. It supports alternate spellings, date formats and other differences between two countries with a shared language.
1
2
3
# ./locales/en_US/LC_MESSAGES/messages.po
msgid "login_message"
msgstr "Hi there!"
1
2
3
# ./locales/en_AU/LC_MESSAGES/messages.po
msgid "login_message"
msgstr "G'Day Mate!"
4. Concatenated Strings
Some developers love to create concatenate pieces of sentences using placeholders, where the order of words and phrases is hard-coded. Splitting sentences into several keys presumes a grammar and a certain sentence structure. If you use conditional statements and you conditionalize single terms or a portion of a sentence, the granularity of conditional text might cause confusion during the translation process.
In this (intentionally bad) example, the structure is fixed and the sentence is broken up into tiny strings:
1
2
3
4
5
msgid "welcome_back_msg_start"
msgstr "Hey "
msgid "welcome_back_msg_end"
msgstr ", welcome back!"
1
2
print(gettext('welcome_back_msg_start') + username + gettext('welcome_back_msg_end'))
# Hey John, welcome back!
These word puzzles are very hard and sometimes almost impossible to translate and will give translators a bitter hatred for your shenanigans, as they may only see parts of the sentence while translating and have to guess what belongs together.
Nobody likes guessing games.
Don’t Assume Grammar Structures And Be Careful With Granularity Of Conditional Text
The structure of the sentence will often be completely different in another language.
Therefore, it is best to create strings that are complete sentences.
Translators must be able to control the structure of the sentence, change the order freely and insert all kinds of prefixes, suffixes and any other grammar elements.
If a string contains a placeholder, always explain what each placeholder means and allow the translator to change the word order if necessary. Sometimes you are safer setting a condition at the sentence level.
Considering the above, here is a better example. The translator can freely move the placeholder and fully control the structure of the sentence:
1
2
msgid "welcome_back_msg"
msgstr "Hey %(username)s, welcome back!"
1
2
print(gettext('welcome_back_msg', username="John"))
# Hey John, welcome back!
5. Corrupted Characters / Lack Of Unicode Support
Whenever you use a wrong character encoding and your source code handles strings using a datatype that can not handle Unicode, translations will break. Often programming languages store files using the system’s default encoding.
However, when your server is English and all of your users are browsing in Chinese, you characters will get corrupted.
Always Use UTF-8
Therefore, another of our software localization best practises is to make sure to always use UTF-8.
It is the best choice 99% of the time as it fixes this issue by standardizing the encodings across browser and server. So ideally every layer in your stack should use UTF-8: HTML, HTTP server, database and the application itself. Only when you’re working primarily with Asian languages, you might need UTF-16.
Specify the charset in the <head> of your HTML document:
1
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Verify your HTTP server is sending the correct HTTP Content-Type header:
1
Content-Type: text/html; charset=utf-8
Use UTF-8 in your database:
1
2
# MySQL
CREATE DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;
6. Hard-Coded Numbers, Units, Dates And Times
Software localization is about more than the mere translation of words, it is about adopting the complete culture.
Hard-coded date, time or currency formats will cause trouble during the translation process, as languages and countries differ in date and time formats. 26.04.2015 or 04.26.2014? 14:00 or 2 p.m.? 1,000 miles or 1,609 kilometers?
Use A Library To Support Different Locale
As previously stated; never hard-code numbers, units, dates, and times, assuming that they don’t need localization.
Have localizable string instead and let translators decide what is the best for their language.
You can store all dates and times in a standard ISO format and use a library to format them for the given locale. It will also help for converting time to different time zones.
The same applies to currencies and other number formats. So, always use a library with localized files for each of the locales you software needs to support.
Example using Pythons babel library:
1
2
3
4
5
6
7
8
from babel.dates import format_datetime
from babel.numbers import format_currency
print(format_datetime(locale='ru_RU'))
# 26 июля 2013 г., 15:48:18
print(format_currency(10.50, 'EUR', locale='de_DE'))
# 10,50 €
print(format_currency(10.50, 'USD', locale='en_AU'))
# US$10.50
7. Not Caring About Vertical Writing And Languages That Read Right To Left
Arabic, Hebrew and some other languages go from right to left and East-Asian languages using Chinese – or traditional Mongolian if you’re feeling adventurous – characters have a long history of vertical writing.
Prepare For Complex Text Flow
Don’t assume that the same rules apply for all languages and expect the need to implement specialised versions for complex text flow; e.g. vertical writing and plan for languages that read right to left.
With regards to vertical writing, strings are for example not rotated by 90 degrees, instead single characters are placed under one another.
You can include a direction string in the resourced strings and use that string to load a different stylesheet based on the current locale. There’s also a direction property in CSS.
Example:
1
2
3
h1 {
direction: rtl;
}
1
2
3
<h1>
Read me from right-to-left.
</h1>
8. Confusion/Ambiguities Due To Lack Of Context
When strings include variables, are used in a specific context or wording is ambiguous, your translation vendor will have a hard time. Usually translators work on files and strings in a context-free format. So, how will a translator know, whether the single term “Contact” is a verb for a button or a noun for a label?
Provide Localization Notes And Use Code Comments
Keep in mind to add comments and notes to the localizable files.
Aside from glossaries and style guides, you can provide context information to translators directly in your source files. The more context you give, by writing notes for translators and providing alternate phrasings, the better.
If you’re working with content in text-based code files (XML, HTML, JSON and so on) make sure to use code comments. If you’re handle your translations in a spreadsheet you can easy add a column for context notes. For a even better understanding, provide screenshots.
Remember that context is king when it comes to software translation and localization – the more context, the better!
9. Images That Contain Text
Images are a great way to save localization costs, as it cuts down the word count for translation and may even make your product easier to understand, not to mention more visually appealing to the user or reader.
However, sometimes images that contain text can pose a serious pain for translators and can slow down and otherwise hinder the translation process. In some cases it could even result in you paying more money.
Separate Text From Graphics
If text must be associated with a graphic, try to separate your text from the image and create the text as a separate component.
If text is separable, managing localized versions becomes a lot simpler.
Ideally, images should not contain text at all, because it eliminates the need to translate it. Also be aware of cross-cultural differences, as not all images and symbols carry the same meaning across borders.
10. Not Worrying About Localization Until It’s Too Late
Small mistakes can prevent your software from working in other languages. Mistakes in source content can be replicated or worse, amplified in various language versions and can cause months fixing localization bugs.
Don’t let this happen to you!
Test Localizability Early And Often
You can save yourself a lot of trouble in the long run when your start testing for localization early and often.
As a developer you can use automated tests of test translation files and character encoding for the localized version of your software.
Always test your patches not just for code errors, but check also strings for grammar errors, capitalization. inconsistencies and localizability issues.
Having localization in mind when creating the original software or app eases the localization process a lot. If you avoid these 10 common pitfalls and follow the best practices detailed in this article, your application should be fully localizable and open up your application to the international market.
Be sure to subscribe and receive all updates from the PhraseApp blog straight to your inbox. You’ll receive software localization best practices, about cultural aspects of breaking into new markets, guides and tutorials for optimizing software translation and other industry insights and information. Don’t miss out!
Don’t always neatly break into categories
Most modern CMS have some capacity to export content and UI for localization. Website builder type services, like Wix, tend to make localization difficult
CMS i18n “robustness” can vary considerably across versions,
Make sure you are “responsive” before even thinking localization.
Copy from other
Image from STS prez
https://phraseapp.com/blog/posts/10-common-mistakes-in-software-localization/
2. Pixel Based Layouts / UI Requires Editing After Translation
Don’t assume every language is as concise as English.
English text is often very compact compared to other languages – like German or Finnish, for example – and translations can be vary considerably in length and density.
If you don’t prepare for this and there isn’t enough space, your strings might overlap other controls and the interface will require editing after translation.
Design For +50% And Give Strings Room To Grow And Shrink
The interface must be able to adjust size to accommodate the length of translations provided at runtime.
You can solve this problem by leaving extra space after each label for the string to grow. However, by doing so the labels and controls might appear pretty far apart from each other in compact languages. Some developers give their labels room to grow and shrink by aligning them to the right or by placing them above the controls.
You can also use layout managers, that understand how locale affects a UI and manage the pixel positioning of widgets for you at runtime, so your interface will adjust properly.
Another way to solve this issue is by storing the dimensions for a label in the locale resource file.
When strings include variables, are used in a specific context or wording is ambiguous, your translation vendor will have a hard time. Usually translators work on files and strings in a context-free format. So, how will a translator know, whether the single term “Contact” is a verb for a button or a noun for a label?
Provide Localization Notes And Use Code Comments
Keep in mind to add comments and notes to the localizable files.
Aside from glossaries and style guides, you can provide context information to translators directly in your source files. The more context you give, by writing notes for translators and providing alternate phrasings, the better.
If you’re working with content in text-based code files (XML, HTML, JSON and so on) make sure to use code comments. If you’re handle your translations in a spreadsheet you can easy add a column for context notes. For a even better understanding, provide screenshots.
Remember that context is king when it comes to software translation and localization – the more context, the better!
https://phraseapp.com/blog/posts/10-common-mistakes-in-software-localization/
Some developers love to create concatenate pieces of sentences using placeholders, where the order of words and phrases is hard-coded. Splitting sentences into several keys presumes a grammar and a certain sentence structure. If you use conditional statements and you conditionalize single terms or a portion of a sentence, the granularity of conditional text might cause confusion during the translation process.
In this (intentionally bad) example, the structure is fixed and the sentence is broken up into tiny strings:
These word puzzles are very hard and sometimes almost impossible to translate and will give translators a bitter hatred for your shenanigans, as they may only see parts of the sentence while translating and have to guess what belongs together.
Nobody likes guessing games.
Don’t Assume Grammar Structures And Be Careful With Granularity Of Conditional Text
The structure of the sentence will often be completely different in another language.
Therefore, it is best to create strings that are complete sentences.
Translators must be able to control the structure of the sentence, change the order freely and insert all kinds of prefixes, suffixes and any other grammar elements.
If a string contains a placeholder, always explain what each placeholder means and allow the translator to change the word order if necessary. Sometimes you are safer setting a condition at the sentence level.
Considering the above, here is a better example. The translator can freely move the placeholder and fully control the structure of the sentence:
Software localization is about more than the mere translation of words, it is about adopting the complete culture.
Hard-coded date, time or currency formats will cause trouble during the translation process, as languages and countries differ in date and time formats. 26.04.2015 or 04.26.2014? 14:00 or 2 p.m.? 1,000 miles or 1,609 kilometers?
Use A Library To Support Different Locale
As previously stated; never hard-code numbers, units, dates, and times, assuming that they don’t need localization.
Have localizable string instead and let translators decide what is the best for their language.
You can store all dates and times in a standard ISO format and use a library to format them for the given locale. It will also help for converting time to different time zones.
The same applies to currencies and other number formats. So, always use a library with localized files for each of the locales you software needs to support.
Example using Pythons babel library:
2. Balance efficiency and practicality
Using variables and concatenation to create catch-all sentences in order to write efficient code is usually high up in the good coder’s credo. However, during internationalization, sometimes less sophistication can prove to be more practical. A concatenation of variables may fix several scenarios in a sentence in your own language, but require a different number, gender or word order once translated. Sometimes it’s even quite hard to make any sense out of them!
The @NUMBERPLURAL @ITEMTYPE(s) will @ACTIONTYPE within @NUMBERSINGULAR day(s).
What if the target language has three different gender inflections? What if the “(s)” trick for plurals doesn’t work at all?
Walk on flags shoes. Not ok in Middle East -have found all sorts of examples of shoe marketing blunders in this article. A famous drug company marketed a new remedy in the United Arab Emirates. To avoid any mistakes they used pictures. The first picture was of someone ill, the next picture showed the person taking the medication, the last picture showed them looking well. They just forgot one detail-in the Arab world, people read from right to left.
Yellow: happiness (north America) or Death (latin America)
Red Auspicious (China) or full of danger (middle east)
Purple Wealth (most of world) or (sorrow, death, and mourning)
https://www.globalme.net/blog/colours-across-cultures
pixabay
Proxy Translation [kicking the black box down the road?]
Localization “Platforms” (vs. tool)
Leading platforms: Transifex, Phraseapp, Lingohub, Crowdin, POEdit, Localize.js, Multilingualizer, Bablic Easyling,Smartling,SmartCAT
,Serge, OneSky, SmartCAT
Benefits: Code neutrality, Visual context, file interchange,no email chains, small chunks, continuous vs. agile
Risks: SEO, translation quality, expense
**Make Magic Quadrant(s) for above
Supported Content Formats
Alchemy CATALYST supports over 170+ different software applications, help and Web file formats. And this can be extended by developing custom parsers using Alchemy ezParse technology.
All Microsoft Desktop Development Platforms: 9x, NT, 2000, XP, Win32, Winx64, VISTA, RC, RESX, .NET Binaries(2.0 and above), Visual Basic.NET, Microsoft WPF
Online Help Systems: Doc-2-Help, RoboHelp, MadCap Flare, Sun Help, Oracle Help, Microsoft Help 2.0 and 3.0
Mobile Computing Platforms: Android Application Packages (APK), Windows CE, Symbian, EPOC
Java Platforms: J2EE, J2SE, J2ME, JAR, .properties, WAS, EAR
Content Files: HTML (and all derivatives PHP, ASP, JSP), XHTML, XML (including derivative ASP.NET, ASP, JSP and XSL), MS Excel, DITA 1.0
Databases:All Microsoft DB technologies, Oracle 8/9/10 and IBM DB2
Miscellaneous Files: ZIP archives, Multilingual Language Packs(.mui), Drivers (.sys), Control Panel Apps .cpl), ActiveX (.ocx), Multilingual Language Packs (.mui), Codec files (.acm, .ax), Screen Savers (.scr) and Borland Library Files (.dpl, .bpl), Microsoft Visual Studio Project files
Pixbay image
Pixabay image
• How often do you release content updates?
• What is the scope and cadence of releases?
• Are you aiming for “sim-ship”? (Simultaneous shipment across all markets Incl. foreign)
• Think about your localization goals: agile or continuous delivery?
• Is it acceptable to distribute localized versions on a schedule other than the US releases?
• How do you ensure that source/English content is prepped for translation? How much is context needed?
• How do you budget for localization expenses? Is it tied to a customer’s order or market research? First-to-market?
• What does your localization team look like? Who is responsible for what?
Did you manage a localization project?
Use localized software?
Had software you developed localized into another language?
http://coq.no/character-tables/en
Specific tools like SDL or Memoq have differing metadata practices, meaning there can be losses when sending an “XLIFF” from one type to another.
