Internationalization (i18n): 4 Services You Should Consider [Cliff Notes]
Share
Click here to close
Click here to close
Subscribe here

Internationalization (i18n): 4 Services You Should Consider [Cliff Notes]

Internationalization (i18n): 4 Services You Should Consider [Cliff Notes]

Cliffs Notes - InternationalizationIf you are new to localization, or if you consider yourself a non-technical localization professional, then this new blog series is for you. The series will explain basic localization concepts, give you what you need to know about each, and help you not get lost in the acronyms and the technical aspects of the industry.

These blogs are not so much about how to get the work done, but about what the work entails.

Today’s topic: Internationalization

Internationalization (i18n) is the process of designing and building a product, usually a website or software, so it can be easily adapted to specific languages and locales. The subsequent adaptation of the internationalized product is called localization (which is the topic of another blog).

Several i18n problems that you may have heard of include:

  • No separation of code and content
  • Inability to handle number and date formats different from the cultural conventions of the source
  • Use of encodings that can’t support international character sets
  • String concatenation (split strings)
  • Strings that aren’t commented; no notes to communicate with translators
  • No specification of string length limitations, and no space for expansion

So what to do about it?

There are four general ways that a localization or internationalization agency can help with identifying and fixing these issues. Skipping the required steps will probably cost you more money, take more time and remaining bugs will impact usability of the end product. During my time in the industry, I have never seen an i18n investment that didn’t pay off. Take this example:

Internationalization bugs grow exponentially with each added language.

10 internationalization errors not caught or ignored
X 5 languages
= 50 bugs to fix        

Don’t put that burden on your testing team, your budget or your schedule!

Below are four basic services that help fix any issue prior to localization.

1. Pseudolocalization

Pseudolocalization, or fake localization, is an initial and partial test of your code. Typically, you will provide the English resource files that contain all the translatable strings, those will be translated into a gibberish language with various characters, and the build is put back together and tested “ad hoc.” You can then get a general sense of whether the build will work in a localized incarnation. You would then fix any found issues, unless you choose to go further with the agency. From there…

2. Internationalization testing

This is a more structured test to determine whether the product was correctly built to work within the language and regional setting conditions that your user might utilize. Simply put, the localization engineer will use a generic set of test cases and sample-test the code with the goal of breaking as much as possible in an amount of time agreed with the client. This pass can uncover general or severe issues, indicate how much work is required and identify where internationalization energies are best focused.

3. Code audit

This is a much deeper dive into the application code than testing can provide. A development engineer will review the entire code base for defects (international functionality issues) with the assistance of special tools and a general knowledge of what to look for and where. The end deliverable is a comprehensive report with problem spots highlighted and remediation examples provided. If the files are full of internationalization bugs and your team does not have the bandwidth, experience or comfort level to resolve the issues, the next service will be required.

4. Code remediation

If the code needs a deep overhaul, then either your internal engineers or agency expert must execute this step. The expert re-engineers the source code to handle specific language conventions in terms of data handled (data analysis, storage, retrieval, display, sorting, searching, and conversion), locale and culture (formatting of numbers, dates, times, and calendars), as well as ensure data space so that the source can support the transition from a single-byte character code (such as English) into languages requiring multiple-byte character codes (such as Japanese, Chinese, or Korean).

Taking these four steps will ensure you avoid keeping your engineers and testers over the weekend, since any bug you didn’t find in the source will probably show up in the localized product.

A localization agency can also provide on-site consultancy or development support to assist your programmers during the coding process, and to bring the internal team through all the steps outlined above. That consultant would act as an extension of your team. His/her work would result in fewer localization issues from the very start. Here is a selection of some useful resources related to internationalization:

If all of the above is Greek to you, then you probably need to consider internationalizing your software or web content. If you are scared that your content has internationalization issues, then it probably does.

{{cta(‘1a665564-4c54-4b91-ba3f-1e4cdc7a3224’)}}

 

Comments