As mobile apps become a dominant form of digital interaction, businesses are looking to expand their reach globally. However, going global isn’t as simple as translating an app’s content from one language to another. Effective mobile app localization is a nuanced process that involves adapting both the technical and cultural aspects of your app for different markets. This blog explores the key strategies for achieving mobile app localization excellence, ensuring your app connects with audiences worldwide.

The Fundamentals of Mobile App Localization

Mobile app localization is more than just translation. It involves modifying the app’s code, user interface (UI), content, and design to create a seamless experience for users in different regions. To do this successfully, businesses must focus on both technical preparedness—known as internationalization (i18n)—and cultural adaptation.

Internationalization: Setting the Stage for Localization

Before you can localize your app, it needs to be internationalized. Internationalization refers to designing your app’s architecture in a way that it can easily support multiple languages, currencies, and cultural norms without significant code changes.

For instance, the app should handle diverse date and time formats, text direction (e.g., left-to-right vs. right-to-left), and measurement systems. By setting up these frameworks in advance, you pave the way for a smoother localization process later on and control costs with preplanning.

Localization: Adapting to Cultural Contexts

Localization, on the other hand, involves making your app culturally relevant. This includes more than just translating text—it’s about ensuring that every aspect of the user experience aligns with local preferences and expectations. From adjusting imagery and colors to adapting regional slang or idioms, localization ensures your app feels “native” to every market you enter.

Key Elements of Mobile App Localization

1. User Interface (UI) Adaptation

The layout and design of your app play a major role in how well it resonates with users from different regions. During localization, it’s crucial to ensure that the UI accommodates longer or shorter text in different languages and adjusts the design for both left-to-right (LTR) and right-to-left (RTL) language formats, such as Arabic.

Some languages, like German or Russian, tend to have longer words, so buttons or menus need to be flexible enough to accommodate these changes without disrupting the user experience. This is especially important for smaller screens on mobile devices, where space is limited.

2. Localization of Visual Elements

Localization doesn’t stop at language. Visual elements, including icons, images, and colors, should also be culturally relevant. For example, color symbolism varies widely across cultures—red might signify good fortune in China but could evoke warning or danger in other parts of the world.

Consider the example of a shopping app: in some regions, displaying gift icons in gold might appeal to cultural preferences, while in others, more neutral tones might be more appropriate. Adapting these elements ensures that users feel a stronger connection to your app and trust the experience you’re providing.

3. Cultural Nuances and User Behavior

Different cultures may interact with mobile apps in different ways. For example, in certain regions, users may prefer apps with more detailed information and features, while others might lean toward a more minimalist, straightforward interface. Understanding local user behavior and preferences is key to crafting a successful user experience.

4. Multilingual App Store Optimization (ASO)

Optimizing your app’s visibility in app stores across different regions is critical. Multilingual App Store Optimization (ASO) involves adjusting your app’s title, description, and keywords for each market’s search preferences. This ensures that users can easily find and download your app, increasing your global visibility and downloads.

Localized ASO also helps you stand out among local competitors, making it easier for users to discover your app in their native language. Without a strong ASO strategy, even a fully localized app may struggle to gain traction in international markets.

5. Performance Testing Across Regions

Localization isn’t just about content—it also involves ensuring that your app performs well across different regions. Factors like network speed, device types, and platform preferences vary greatly from one region to another. Localized performance testing ensures that your app remains fast, responsive, and reliable, no matter where users are located.

Regular testing helps identify potential issues with speed, crashes, or compatibility across different devices and operating systems. This proactive approach ensures that users everywhere continue to enjoy a high-quality app experience.

Best Practices for Mobile App Localization

1. Start With Internationalization

Ensure your app’s framework can easily adapt to various languages, formats, and cultural norms. This includes preparing your codebase to support different scripts, currencies, and text lengths. By preparing the framework from conception for internationalization, you can avoid additional engineering costs down the road.

2. Collaborate With Native Linguists

Automated tools can speed up translation, but working with native-speaking linguists, who are experienced in the type of app, ensures that your app’s tone and message resonate authentically with local users. Native linguists understand the nuances of local slang, idioms, and cultural context, making your app feel truly localized. Ensure consistency by defining the style and key terms for each language and use translation memory that will facilitate future updates.

3. Conduct Comprehensive Testing

Don’t stop at functional testing—incorporate linguistic and cultural testing to ensure that your app reads and functions properly in all its localized versions. This includes checking how the text fits in the interface and whether cultural references are understood correctly which is really a crucial QA step.

4. Keep Iterating

Localization is an ongoing process. As your app grows and expands into new markets, continue to update and refine localized content based on user feedback and market trends. This approach keeps your app relevant and engaging over time.

Conclusion

Mobile app localization is a powerful strategy for expanding your digital presence in global markets. By focusing on both the technical and cultural aspects of localization, you can create a product that not only reaches new users but resonates with them deeply. With a well-executed localization strategy, your app can thrive in diverse markets, providing a seamless and enjoyable experience for users around the world.

The road to mobile app localization excellence may be challenging, but with careful planning and execution, you can bridge the gap between code and culture, ensuring your app’s success on the global stage.

References:

• Localize your app  |  Android Developers
• Localization vs. Internationalization

The post Mobile App Localization: Bridging the Gap Between Code and Culture for Global Success appeared first on Globalization Partners International.

What is Pseudo Localization?

Let’s start this article by defining the word “Pseudo localization”.

Pseudo means pretended and not real. Therefore, pseudo localization means localization that is not real.

Pseudo localization is a way of testing the content of an application or software to demonstrate that it is suitable to be internationalized and localized.

All translatable strings in an application are replaced with text strings that are very similar to the target language. Still, instead of containing an actual translation, they contain text with multiple alterations, such as banned characters, longer text strings, or text with a different direction.

Pseudo Localization Process

The pseudo-localization process aims to find errors in localizable elements before it’s too late.

In addition, it also serves to simulate the final result of the localized object and estimate the additional effort to be able to fix it before delivery.

Some problems that pseudo-localization can detect are:

• Corrupted characters: Here you can see if your application engine is e.g., ASCII or ANSI characters are supported.
• Text that does not fit in the graphical interface and needs to be shortened or trimmed.
• Interface issues with right-to-left languages.
• Problems with languages whose characters may differ from those in the source language. Some languages, e.g., Swedish for example, contain characters (Å, Ä, and Ö) that are not in the English language and can therefore cause problems if the application is not prepared for them.

Additionally, pseudo-localization is very useful for detecting text that has been translated but should not be translated.

Where is it Used?

During the development of some applications and operating systems, such as Windows, various builds allowed the use of language packs with pseudo-locals.

These pseudo-locals contained text strings identical to those in English, except that the characters were changed to English-like characters but with accents and characters from other languages. This is very useful because the text is not completely gibberish but is perfectly understandable and it provided a very good way of detecting localization problems, even being able to read the text strings.

Can you read this?

[Шěđлеśđαỳ !!!], 21 ōf [Děcěmßëŕ !!] ōf 2022.

Conclusion

Pseudo-localization allows you to verify that your product is localizable without having to localize it into an actual language. Many potential localization issues can be discovered without the need for an actual translation.

Let’s imagine what would happen if placeholders or tags get translated. If these are unintentionally “translated,” the build could fail, or the app could crash during use.

Pseudo localization results are not only useful for the software localization process, but it is also useful in the document localization process to estimate DTP efforts and detect text that has not been included for translation.

Pseudo localization also aids in the identification and rectification of hard-coded text strings, fostering a more robust, concrete, and maintainable code base, allowing developers to check for language support, text expansion, truncated text, and formatting without the need for actual translations.

The post Pseudo Localization and Why It’s Important appeared first on Globalization Partners International.

When building an application, it is not a question of if it might be used by a global audience, but a matter of when it will be offered to global markets. This is why it is important to build an application with internationalization (i18n) in mind.

Planning to support multiple languages, not only includes the GUI (graphical user interface), but also other aspects like formatting dates and numbers, applying different currencies, and supporting language-specific fonts (including bi-directional). Depending on the framework or content management system (CMS) you are going to use to build your application, you might have different alternatives to internationalize it. In this blog, we will cover the best practices for the internationalization process of an Angular app.

Overview

To internationalize your Angular app to support multiple languages; follow these steps:

1- Install needed dependencies.

2- Prepare project for translation.

3- Extract text to be sent to translator.

4 – Use .xlf file after translation and set project to localization.

Let’s start our journey.

Install Dependencies

Install a localized package to a project by using the Angular CLI and (ng add @angular/localize) command, then we will add the @angular/localize package, afterward, the package.json file will be updated.

Prepare Components for Translation

Prepare the Value of an Element

To prepare the fixed text in the template, we will use the i18n attribute to mark all static text to be translated;

We must place the i18n attribute on every element tag we want to translate.

Example:

<h1 i18n> Welcome in GPI! </h1>

We added the i18n attribute in the element to mark the h1 element tag as a translatable element.

When Angular executes the extract process, it will understand that the h1 tag is to be translated.

Prepare the Attribute of an Element

To mark the title attribute for translation, you will add i18n-title.

Example:

<img [src]=”logo” i18n-title title=”GPI logo” alt=” GPI logo”/>

In the previous example we used the following format to mark the “title” attribute for translation:

i18n-{attribute_name}=”{i18n_metadata}” {attribute_name}=”{attribute_value}”

Preparing Text in Component Code

As we use a variable in the ts class, we need to also mark this text for translation, to do that we use backtick (`) characters to surround the text and metadata.

For text only:

$localize `string_to_translate`;

To add i18n metadata we will surround it by (:) as shown here:

$localize `:{i18n_metadata}:string_to_translate`

When we need to include interpolated text, will use this format:

$localize `string_to_translate ${variable_name}:placeholder_name:`;

Preparing Plural Expressions

The difficulty with plural expressions is that different languages have different pluralization rules. To mark plural expressions, we use the plural clause:

{ component_property, plural, pluralization_categories },

Notice that we will put plural in the (pluralization_categories) part:

Example : =0 { } zero { }

Notice this example:

( updated x minutes ago )

<span i18n>Updated X minutes ago </span>

We can mark it as:

<span i18n>Updated {minutes, plural, =0 {just now} =1 {one minute ago} other

{{{minutes}} minutes ago}}</span>

For more detailed information about the pluralization category, check out  Angular Documentation.

Preparing Alternate Expressions

We can use the (select) clause to mark choices for alternate text:

Format: { component_property, select, selection_categories }

We enter the text (English) surrounded by the curly brace ({}) characters after the selection category:

<span i18n>The main course is {main_course, select, meat { meat } fish { fish } other {other}}</span>

Export Content for Translation

Now that we have finished preparing the components, we will extract all marked text by using Angular CLI.

By using ”extract-i18n” command, Angular will create a source language file named “messages.xlf ” and it will be created in the root directory.

To create the file in specific directory we can use: “ng extract-i18n –output-path src/locale”

Then, create a copy of the file for each language; we rename each language file depending on the locale needed following this format:

file_name.{locale}.xlf  like   messages.fr.xlf

it is preferred to create a directory for translation files like: src/locale inside .xlf file, we will find the <trans-unit> tag for every marked text. Inside this tag there is tag <source>, this tag contains marked source text.

The translator can use the xlf editor App or manually by adding a new tag named <target> and write the value inside.

Simple example:

<trans-unit id=”introduction” datatype=”html”>

<source>Hello</source>

<target>Bonjour</target

</trans-unit>

Import Translated Content

Now we need to prepare the app for localization by adding specific properties in angulal.json file.

As in next snippet code, we will add the new property “i18n” and we will specify the source locale that is the locale used in source code.

We will add other property “locales” and the specific locales that the App can support.

Once we finish, we need to merge the translations into our application.

Go to the angular.json file and add new settings

“i18n”: {

“sourceLocale”: “en-US”,

“locales”: {

“fr-CA”:”src/locale/messages.fr.xlf”,

//.. } }

Moreover, we will add another property in this path: architect > build > options

Add “localize”: true

Now the app is ready to build; by using Angular CLI, we will write this command “ng build –localize”.

For more details and in-depth understanding please check Angular Documentation.

Format Data Based on Locale

We will use the pipes that Angular provides for this purpose, notice the data transformation pipes use the LOCALE_ID token to format data based on rules of each locale.

Currencies Formatting

Using CurrencyPipe transforms a number into a currency string.

currencyObj: number = 0.359;

{{currencyObj | currency}}  // output ‘$0.36’

Numbers Formatting

Decimal Pipe transforms a number into a decimal number string.

pi: number = 3.14159265359;

Without specified formatting:

{{pi | number}}    output: ‘3.142’

With specified formatting:

{{pi | number:’4.1-5′}} output: ‘0,003.14159’

With specified formatting and locale:

{{pi | number:’4.1-5′:’fr’}}  output: ‘0 003,14159’

Numbers Dates

Use DatePipe to format a date value.

dateObj: number = Date.now();

{{ dateObj | date }} // output is ‘Jun 15, 2022’

or format like

{{ dateObj | date:’medium’ }} // output is ‘Jun 15, 2022, 9:43:11 PM’

Conclusion

The localization of an application is an important aspect to consider when starting the design process. By developing the application to be language-independent and able to handle the intricacies of multiple languages from inception, you will save time and money.

With the continued growth of the global marketplace, most websites nowadays are prepared for localization. Angular makes this process easier by providing simple localization techniques, with simple steps to follow, you can get a fully localized application. Designing an application with localization in mind is the best practice to avoid a lot of complexity when localization is introduced at later stages of the project lifecycle.

The post Best Practices for Angular Internationalization appeared first on Globalization Partners International.

Front-End development has become a popular career these days and it plays a very important role in the software development life cycle. As part of this blog, we will check the fundamentals of this career and some related concepts. Let’s take a quick look!

What is Front-End Development?

In the modern software development life cycle, it’s common to separate client-side and server-side development. Front-End development is also referred to as client-side development, while Back-End development corresponds to the server-side.

In other words, Front-End Development is the development of the Graphical User Interface (GUI), focused on everything the user will see and interact within the software.

What Do We Need to Develop on the Front-End?

If we state that Front-End web development is everything on the browser (GUI), it will then involve all that is needed for the browser to produce the user interface (UI). Some of the key elements involved on this are:

• Hypertext Markup Language (HTML)
• Cascading Style Sheets (CSS)
• JavaScript
• Web Assembly

A webpage includes a group of HTML elements that will define the content of the page. These HTML elements have different types. For example, there are elements to create forms, like text inputs, select lists, and buttons.

Sometimes these elements will need to be formatted to have a specific color, border, size, etc. Here is where CSS (Cascading Style Sheets) plays its part.

What about JavaScript? In simple terms, it’s a programming language that allows dynamic behaviors on website pages. By using JavaScript, we will interact with the elements and control their functions. Nobody wants to be a front-end developer without JavaScript. Not to mention that JavaScript manipulates the DOM (document object model), which makes up the base kernel for any modern front-end framework.

DOM Overview

The DOM (Document Object Model) is an API, DOM represents an XML or HTML document, and DOM is loaded in the browser. When a document is read through DOM, every part of document is what we call a “node”. The document represents a nodes tree, every node can have other nodes as children. Through DOM, we can programmatically interact with the document and add or remove nodes.

We can listen to changes and interactions of the node. A node is a programmatic object with properties. It is worth mentioning here that, in order to access any node, we need to use X-Path or full-path concept.

We can consider X-Path a unique address of the node, it indicates the location of the node through its parent, to the root. By giving every node an index number and level number, we will have a unique address of every node.

What is a Framework?

In simple terms, a software framework is a set of programmed functionalities that can be reused or extended, without the need of knowing the details of its implementation. It can be modified by adding more code segments. It provides a standard way to execute functionality and build software. It provides functionality as part of a larger software to make the development of software easier.

The framework uses shared resources, libraries, images, files, and references, and groups them in one package. This package can be modified to meet the needs of the project. The developer can also make use and take advantage of other libraries to create their own frameworks.

Conclusion

Building software is not just writing code; it’s a process that involves a lot of effort. That is why developers will always need a framework. When we write a large software program, we will start by building the framework with functionality that we will reuse for our software, based on existing frameworks.

We will need an abstract (generic) framework to help us in the development stage. It is time-saving and helps us focus only on our specific system functionality. Nowadays, there are several frameworks for website Front-End development. Some popular options are Angular, React, etc. They are more than just frameworks as they are also platforms ideal for developing front-end web applications.

The post Front-End Development Fundamentals appeared first on Globalization Partners International.

It is known that the software ecosystem has become pervasive. Programmers around the world grew to 23.9 million in 2019 and are expected to reach just under 29 million in 2024 according to Statista. Despite that and what developers have seen, more than 80% of applications are not utilized. In this blog, I will take you on a simple journey of understanding SOLID principles towards powerful software development.

Software development has a simple design process: it starts with architecture, ends by testing then passes by coding. Programs are essentially lines of codes written to perform specific functionality. At some point, this functionality will need modifications to adapt and evolve. Programmers need to remember the golden rule when starting to code: that software has to be maintainable, extensible, updatable, and testable.

What does a “Clean Code” mean?

You can think of a “clean code” as the key that will accompany you throughout the software development. Oftentimes, developers would complain that it is difficult to read and understand the code. Whether it is too long, ambiguous words, or as if someone just made it up. It’s funny that sometimes the one who wrote the code is the one who couldn’t understand it. Soon enough, the code needs to be revised following its first release. Sometimes within a month or even a week! Many developers fell into this “rabbit hole”.

Anyone can read a book about software programming and then write executable code to run on the machine. Truth be told, a computer can still execute poorly written code, but not many developers can write human understandable code. Remember that clean code is the key to your software development journey. It will help you and other developers understand the “twists and turns” of your program without unnecessary complexity. Easy to read code means easy to change.

Software Maintenance

This means the ability to change any part of the code without negatively affecting another part at any point in time. This is essential to keep up with market needs and compete with the ever-changing software ecosystem.

Software Extension

It is the capability to add more functionalities and update any part of the base program without impairing the entire system or another part at any time. Most programs are planned for future expansions to sustain users’ demand in the long run.

Software testing

This means the ability to validate the functionality of any part of the program. Testing can be done alone or with a sample group of intended users. Quality assurance is obtained through a series of software testing.

Software quality depends on the fulfilment of certain rules and criteria according to specific design principles and patterns. It is more than just doing the job. The rule is to maintain the software functionality, while the criteria are the assessment tools to know whether the entire system functionality or in part, is achieved.

Who sets the design principles and patterns?

They are the programming experts who have faced and endured many coding obstacles. They have tried countless solutions and documented their knowledge to write the rules derived from the principles.

It is worth mentioning that most of the design principles and patterns are entirely based on what is known as Object-Oriented-Programming (OOP) such as Object, Inheritance, Polymorphism, Abstraction, Interface, and more.

What does SOLID mean?

In 2004, Michael Feathers introduced a pseudonym derived from the 5 software design principles known as:

S – Single Responsibility Principle

O – Open-Closed Principle

L – Pliskova Substitution Principle

I – Interface Segregation Principle

D – Dependency Inversion Principle

Responsibility Principle

Think of the code as modules. A module is a part of a program (or code) that can function alone such as procedure, method, class, etc. Responsibility of the module means to perform only the job that module is supposed to do. For example, if there is a class that gets data from the database, we can say that its responsibility is ‘reading data’. If there is a method to check the connection of a database, then we can consider that its responsibility is ‘connection check’.

To understand the Responsibility concept in more detail, let me tell you about Coupling.

Coupling

This means the depth of the relationship between the modules. When the coupling is low, the software will be stronger and easy to maintain. This concept is also known as Loose Coupling.

For example, your program needs to perform a function: to get the employees’ data from the database. We will then have three classes to perform.

• The data model class contains employees’ identity properties like Id, Name, Phone, Email, etc.
• The class that will fetch data from the database, we usually call it a Repository.
• Then the class that will be called from the Application Programming Interface (API), we can call it EmployeeController.

The above three modules have coupling: Controller depends on Repository, and then Repository will need Data Model. To lose this coupling, we will need to use some design patterns like Dependency Injection and Reflection.

Cohesion

This concept is the reverse of coupling.
For example, we need a data model class of the users that will contain properties like Id, Name, Phone, Email, etc. But what if there’s a company Name and Branch as well?

To apply cohesion, the user data model has to contain only user data and create other data model class for company data. Remember, cohesion is the opposite of the coupling concept. It means that the more cohesion among the same class members, the project will be more sustainable, which is essential for software maintenance.

Conclusion

Software development and its ecosystem are growing fast. Anyone can read a book about software programming and then write executable code to run on the machine. Although a computer can still execute poorly written code, good developers must write human-readable code. Programmers need to remember the golden rule: that software must be maintainable, extensible, updatable, and testable. Understanding the SOLID principles and “clean code” concept will save programmers from falling into the “rabbit hole” of unnecessary revisions. Remember, successful software endures both the test of quality and the test of time.

The post SOLID: Towards Powerful Software Development appeared first on Globalization Partners International.

Have you ever thought about being a localization engineer? Localization engineers facilitate the entire localization process. They act as bridges between the different stakeholders: clients, business development teams, project managers, and vendors.

And what exactly do they do? The role of a localization engineer varies depending on the company’s size and scope. At the basic level, the role could be running QA checks on localized files before delivering them to the client to make sure that they’re error-free. Sometimes the role extends to supporting project managers and the sales and business development teams due to the knowledge about computer-aided translation (CAT) tools, content management systems (CMSs), and other relevant localization information. Finally, on a higher level, the localization engineering role could involve developing a new tool or plugin that supports localization processes that require a solid background in development and programming.

Through a series of blogs, I’ll share some ideas and challenges facing the localization industry. In this blog, I’ll talk about localization engineering skills through the last decade and in the future with the era of big data and automation.

Skills for a Localization Engineer

To be recognized as a good localization engineer, you need to have particular skills and develop them regularly. Here are some examples of important skills to have and hone.

Problem Solver

In the localization industry, usually only a small number of projects tend to go according to the plan at the beginning. Skilled localization engineers can work analytically to understand the problems that they’re facing, the available solutions, and the optimum solution to get the required result.

Knowledgeable About Trends and Research-Oriented

There’s always something new in the localization industry, so a successful localization engineer will keep up-to-date and learn about trends in the industry. In addition, he or she will research ways of doing things and handling problems in multiple ways.

Adaptable

An adaptable localization engineer who can think outside of the box is usually good about finding creative solutions for challenges. When one is adaptable, one can better face challenges.

Detailed-Oriented

The localization industry is full of details, so being a detailed-oriented localization engineer means completing each task, assignment, or phase as flawlessly as possible before moving on to the next one.

Good Teamwork Spirit

The localization industry requires an entire team effort; it’s not a one-person show. Since a localization engineer is at the center of all the stakeholders (e.g., project managers, sales team, translators, vendors, etc.), a successful localization engineer is must know how to work with everyone.

Strong Communication Skills

As we just talked about, a localization engineer knows that localization requires teamwork and that the localization engineering role is the center of all the stakeholders. Therefore, a localization engineer must have very strong communication skills with all stakeholders.

The Role of the Localization Engineer in the Future

Without a doubt, the COVID-19 pandemic has accelerated and intensified the digitization or digital transformation for all activities and industries around us, which has had a huge and direct impact on the localization industry. The pandemic and other factors forced most the localization companies to automate any repetitive tasks, procedures, processes or workflows with the same pattern, which means more involvement for machine translation (MT) and artificial intelligence (AI) in localization daily tasks such as machine translation, transcription, text to speech, speech to text, and more.

MT and AI play a big role in the localization industry now, and they will continue to play a greater role in the future. However, this doesn’t mean that the localization engineering position will go away—it’ll just change, and the changes will be something to embrace. So while the skills that we talked about previously were enough in the previous decade, nowadays you need to learn some additional skills with technology to meet the new needs and challenges of the industry.

Capability to Work on Various Types of Source Files

Currently, many companies from different industries work with a variety of file types and schemes. Simple file formats like Microsoft applications (Word, Excel, and PowerPoint) and more professional tools like Adobe InDesign, Illustrator, or FrameMaker are relatively easy to be localized. However, many other files formats like .OP, .HTM, .YAML, and .JSON requires a higher level of technical knowledge to make sure that final localized files will be error-free and to avoid any unnecessary back and forth between clients and linguists.

Capability to Work on Multiple Tools and Platforms

In the age of automation, it’s crucial to have excellent knowledge and understanding of tools and platforms. This is important so that you select the most appropriate tool to extract translatable text, analyze its word count, and prepare the localization package. If you don’t choose the most appropriate tool or finalize these steps correctly, you’ll disrupt the workflow process while also increasing the overall project cost.

Skilled Coder

Last but not least, you must be able to read code and be familiar with many different programming languages. This became mandatory, not just nice to have like it was previously, because a localization engineer will work with all different types of files that have different formats and schemes. Sometimes you need to deal with customized CMSs or translation management systems (TMSs) that require you to create ways or tools to overcome challenges like using connectors with CMSs, macros or scripts with TMSs.

Localization Engineering at GPI

Our localization engineering team at GPI works hand-in-hand with all our stakeholders to increase efficiencies by automating any repetitive task while still ensuring a high-quality final deliverable. We’re also always looking for ways to make things easier for our clients.

The post Skills for a Localization Engineer appeared first on Globalization Partners International.

The first microcomputers supported ASCII. Occasionally some letters with accents and symbols and occasionally characters in Russian or Armenian alphabets were included. However, the Arabic alphabet is a little more complicated, it is written from right to left, utilizes different characters, and requires many diacritics to be understood.

What Were the First Computers To Support Arabic?

Xerox Star 8010

In the late 70s, a team at Xerox began work on a vision: “office of the future”. Most of the technology we use today (windows, the mouse, clickable elements, icons, etc.) had their origin from the Xerox Star 8010.

This system had interesting multilingual capabilities. Unlike any other systems that used 8-bit character encoding, the Star 8010 used 16-bit codes to allow a wider range of characters, input systems, as well as fonts, which had to be designed to support other writing systems like Arabic. It was not easy and intelligent rendering algorithms had to be written to work with Arabic characters.

“Arapple” Arabic Apple II (1979)

The Apple II supported rudimentary Arabic versions and has specialized chips inside to produce and understand the Arabic characters.

Sinclair ZX Spectrum

The Sinclair ZX Spectrum had a rare Arabic version with a switch at the front, to select between the original and the Arabic ROM.

The Arabic ROM includes support for right-to-left writing, and diacritics.

MSX Home Computer

MSX systems was popular in Japan, South Korea, Argentina, and Brazil. It was also popular in the Gulf region where Arabic characters are used. Classrooms with Yamaha MSX computers were common for teaching informatics in some Arab countries.

MSX designed a variation specifically for Arabic countries, including MSX Al Fateh 100, Al Fateh 123, and Sakhr AH-200.

What About Operating Systems?

Microsoft DOS and Windows

In 1988, Microsoft introduced MS-DOS 3.3 with support for the Arabic language. The programs running in this version of DOS worked normally like any other version, although it consumed a more memory than the English version.

The operating system had an Arabic interface and allowed the user to map shortcut keys to switch between English and Arabic. In theory, any well-built program could run in bilingual mode, allowing right-to-left typing, with the character formation required by the Arabic language.

Microsoft gradually incorporated Unicode support in Windows, beginning with Windows NT and Windows 95, influencing the “Arabization” of software products. Microsoft also added support for Unicode to some of their productivity applications, for example Office 97.

Mac OS

Arabic is fully supported on macOS now, although it was not always the case. Apple added support for basic Arabic in System 4.1 and started selling the “Arabic and Persian Language Kit” commercially in 1993. This kit allowed the user to switch between the computer’s main language and Arabic or Persian languages.

It also allows the user enter, edit, or print any Arabic or Persian text and multilingual content with other languages in the same document, or even in the same sentence.

The introduction of Mac OS X 10 did not originally include support for Arabic as Mac OS 9.

Mac OS X 10 supported a handful of language support packs, but Arabic was not included. Mac OS X 10.2 and later versions re-introduced some support for Arabic, officially giving full support in Mac OS 10.4 and onwards.

Conclusion

In most operating systems and applications, Arabic is fully supported. Arabic is the official language in 26 countries, with around 300 million native speakers worldwide, making it the fifth most spoken language in the world.

Over the years, technology and operating systems have developed, as seen above.  Now, in most operating systems and applications, Arabic is fully supported. Arabic is the official language in 26 countries, with around 300 million native speakers worldwide, making it the fifth most spoken language worldwide. Your translation provider must have the tools and capabilities to work with languages such as Arabic and Russian.

The post Arabic Support in Early Computers appeared first on Globalization Partners International.

Have you ever found strange characters like these ���  when viewing content in applications or websites in other languages? What are these and where do they come from?

Finding these strange, apparently misplaced characters is most likely the result of encoding issues and can be a headache.  This occurs many times in the localization field as content crosses borders, platforms and languages.

Character Encoding

Everything on a computer is a number. If we want to have letters on computers, we must all agree on which number corresponds to which letter. This is called “character encoding”.

Character encoding refers to how “character sets” for different languages are assigned to computers. They are defined in “code pages” or “character maps”. These tables combine characters with specific sequences of ones and zeros.

The simplest encoding is called ASCII. ASCII characters are stored using only 7 bits, which means that there are only 2⁷ = 128  characters possible.

ASCII works great for encoding basic characters in English/Latin, but there are over 128 characters in the world!

Things got complicated when Asian languages and computers met. In some languages, such as Chinese for example, you have up to 60,000 different characters. This is where 16-bit encoding schemes appear, giving the ability to store up to 64,000 characters.

Japan, for example, does not use ASCII and simply created its own encodings, having up to 4 simultaneously. All of them incompatible with each other.  So, if for example, you sent a document from one Japanese computer to another computer with the incorrect encoding, the text would be broken.

The Japanese have a term for this phenomenon: Mojibake

Some languages affected by mojibake:

• Arabic
• French
• English: It may appear in some characters such as em dashes (—) or dashes (-). It rarely affects the characters of the alphabet.
• Japanese
• Chinese: In Chinese, this phenomenon is called 亂碼(Luàn mǎ) or ‘chaotic code’.
• Languages based on Cyrillic alphabet: Mojibake also affects languages such as Russian, Ukrainian, Belarusian or Tajik. In languages such as Bulgarian, mojibake is also translated as “monkey’s alphabet” and in Serbian is known as “garbage”.
• Polish
• Nordic languages: Mojibake affects Nordic languages although it is not common. Finnish and Swedish use the same alphabet as the English alphabet, with three new letters: å, ä and ö.
• Spanish: Mojibake in Spanish can be translated as “deformation” and the same happens as in the Nordic languages: Spanish uses 26 standard Latin characters but at the same time includes letters such as ñ, accents and sometimes ü. These characters, because they are not available in ASCII, are displayed incorrectly.

Unicode to the rescue

Finally, someone had enough and decided to create a standard to unify all coding standards. This standard is called Unicode and is not an actual encoding, but a character set.

Unicode has a code space of 1,114,112 possible positions. Sufficient for languages like Arabic, Russian, Japanese, Korean, Chinese, European languages, etc. and even for characters that do not exist. By using Unicode you can write a document in any language.

UTF-8 or UTF-32?

UTF-32 is a Unicode character encoding that uses a 32-bit number for each character. This makes a lot of sense, but it wastes a lot of space. An English document would occupy 4 times as much as it should.

Why do we need such a large number to contain 1,112,064 values, when most of the time we will only use the first 128 values?

UTF-8 is a “variable-length encoding”. That means most of the time, each character only takes up 8 bits, but can expand up to 32 bits if necessary. This system can support any Unicode character without wasting space, which has made it the most popular character encoding.

Conclusion

Today the most used standard is UTF-8 since it can encode any character and is backward compatible with ASCII. In addition, UTF-8 is relatively efficient in terms of space, which makes it the most efficient encoding standard for most cases.

Making sure your application is “localization ready” is key to developing applications that can be easily localized.  Supporting different character encodings and choosing the right encoding are two crucial steps in localization projects, either for websites or software localization.

The post Mojibake: Question Marks, Strange Characters and Other Issues. appeared first on Globalization Partners International.

Most developers code their applications in their mother tongue, then they consider translating or localizing their software. This software development practice depends on the home market for the software publisher as a starting point, and then the popularity of their apps among users and potential markets for new users across the globe.

It is important before starting to translate or localize your software for new locales (country, language, culture), you must consider some software localization best practices to ensure successful marketing and adoption of your application in the target markets you are going after.

Some key questions to ask if you want to follow software translation best practices. 

1. What are the TL’s (Target languages and locales)?

a. Does the software to be localized support the selected TL’s or will it require some amendments and changes to operate them, as some languages ​​such as Arabic, Hebrew, and Persian may not be supported in the app?
b. What is the target country, and is there a locale to be considered? Classical Arabic is used in newspapers in all Arab countries, but if the app targets a region or a specific country and the client wishes to use a local version of the language, this should be taken into consideration. Similar to the case with Spanish that may be targeted towards Europe or Latin America, in addition, French that may be targeted to Europe or Canada.

2. Have you translated similar software or documentation into languages which can be leveraged as reference material for developing a glossary of terminology for the current application you are translating?  Are their previous translation memories that could be used when translating the new app?

3. What is the most appropriate CAT Tool for translating the application? To answer this question, the type of application to be localized must be identified as each CAT Tool can perform the task of translation better based on the app itself:

a. If the application contains interactive forms, tools such as Passolo or Catalyst Alchemy might be the tools of choice and considered the best practice for translating the software.
b. If the application contains data or (placeholders), Trados Studio might be the right option and best practice for translating the software to preserve the locations of such values.

4. What are the best practices for testing the localized software? Several factors to be considered include:

a. Will the translated version of the software be installed for testing?
b. Which devices are required for installing the software and performing the tests?
c. Which translators/testers/QA specialists will test the application from a functional perspective and which from a linguistic perspective?
d. Who will develop the test scenarios and scripts?
e. What is the best way to share the (bugs) between the translation/testing team and the developer team?

Conclusion 

Following the best practices with software localization takes a commitment to planning and practice. While this blog doesn’t cover all the best practices in detail, it should give you a good start on what to think about as you plan your next software localization effort. Look for future GPI blogs on software localization topics to help you enter and succeed in new global markets.

The post Software Localization Best Practices appeared first on Globalization Partners International.

XML is a language designed to simplify the transfer of data between systems. It allows users to exchange information without having to worry about incompatibility between the systems. It’s important to mention that XML does nothing on its own. It’s designed to carry data, not display it. It is a standard for everyone. It is safe, convenient and interoperable.

What rules must be followed to ensure the quality of an XML file?

• All XML elements must have a closing tag.
• Tags are case-sensitive.
• All elements must be nested.
• All XML documents must have a root element.
• Attributes must be quoted.

XLIFF Files

XLIFF files are frequently used in the localization industry because of their simplicity and interoperability. Most CAT tools support them. XLIFF files are basically XML files that contain a collection of translation units. A translation unit contains a paragraph that is extracted from the source document and is inside the <source> element. The translated text will go inside the <target> element. Alternatively, legacy translations from other projects can be added to <alt-trans> to be used as a guideline or reference.

Below are various XML files and implementations of the XLIFF standard:

• TMX: an open XML standard used for exchanging translation memory information.
• XLIFF: created to standardize the way localizable data is passed between tools.
• TTX: Trados Tag Editor files created from different file formats (HTML/JSP/ASP/RT/DOC).
• SDLXLIFF: XML based file format designed to work with Trados Studio. Compliant with XLIFF version 1.2.
• MQXLIFF: similar to SDLXLIFF but used in MemoQ.

XML Benefits

• Encoding: XML provides a clear mechanism to identify the type of encoding used in the document.

                <?xml version=”1.0″ encoding=”UTF-16″ standalone=”no” ?>

• Metadata: XML can provide relevant information for localization.

<source-language=”en-US” target-language=”es-AR”..>
<source xml:lang=”en-us”>GPI is a localization company established in the USA</source>
<target xml:lang=”es-ar”>GPI es una empresa de localización establecida en los Estados Unidos.</target>

• Escape Mechanism: XML offers a way to escape extended characters. This allows the document to contain any character, even if it is not supported by the encoding used by the document. For example, Japanese characters can be escaped if a given document uses an encoding where Japanese symbols are not supported.
• It’s human-readable.
• It separates formatting from the actual content.

Scenarios where XML is not appropriate for localization:

• When it is poorly formed.
• When there is translatable content in the attributes.
• When there is not enough metadata to distinguish the different segments.
• When there is HTML content in the CDATA section.
• When there are bad implementations of other standards, such as XLIFF.

XML Parsing

To correctly translate an XML file, it must be well parsed.

When parsing, you should consider:

• Which elements and attributes are translatable/untranslatable.
• Structural elements, like tags, which can break a segment.
• Elements that have pre-formatted content, such as white spaces.
• Any other element that must be parsed with other specific rules (ex: script section).

When you should consider writing a customer parser:

• When tags in the CDATA section are counted as translatable and shown in the editor.
• When specific elements are not translatable and are meant to be excluded.
• When a generic parser doesn’t adjust to the XML you throw at it. So, there will be no contextual information for the segments. Is it a list? A paragraph? An item? Writing a custom parser allows you to differentiate this.
• When length restrictions are needed.
• When the validity of XML cannot be assured.

Some CAT tools such as Trados Studio come with a generic file type called “AnyXML”. Although this file type is suitable most of the time, it is recommended to tweak it or create a new one if your source file is not displaying properly.

Summary

When conducting a software globalization project you will need to work with XLIFF files, which are XML files containing a collection of translation units. In this blog, we covered which rules must be followed when working with XML files, the benefits of XML files and what role they play in software localization.

Whether you are localizing a mobile application into Arabic or complex security applications into Spanish, it is vital to work with a development team familiar with software internationalization who can localize, test and publish language versions of your software.

The post The Role of XML in Localization appeared first on Globalization Partners International.