Tag: Internationalization

SDL Tados 2021

Project Underwear Q&A in Upcoming Webinar

Localization Strategy

How do people engage with and consume content online? Featured next week as a guest in a Lingoport webinar on language’s impact on online behavior, Nimdzi co-founder Tucker Johnson plans to discuss this and other questions with Lingoport CEO Adam Asnes. The material comes in large part from Nimdzi’s Project Underwear, which attempts to answer how people act if given the choice between English and their native language, and if they would they consume more if there were more content in their native language.

Project Underwear was created as part of Nimdzi co-founder Renato Beninatto’s idea that consuming content and making buying decisions can be profoundly intimate activities. Accordingly, considering how a brand interacts with someone in their underwear — or as Beninatto calls it, the Underwear Effect — creators of content and products might discover more effective methods of drawing in a larger consumer base.

More specifically, Project Underwear considers how the intimacy of one’s mother tongue can impact one’s decisions to engage with products. Whether communicating with users by email or other methods, the prospects of localizing outreach have broad implications.

With end-user surveys with 25 questions translated into 66 languages in more than 70 countries, Nimdzi understood from the beginning of Project Underwear that localizing language would be key not only to obtaining results without biases, but also to put into practice the foundational philosophy — to reach users in their native tongue.

Obtaining a notable sample size of more than 9,000 individual replies, Project Underwear will utilize data on each respondent’s language, gender, age, and primary occupation, that “allow for further segmentation of user preferences” to determine macro-trends occurring in shopping habits and buyer language preferences.

The host of the webinar is Lingoport, a company that provides internationalization products and services that help companies build localized software. The event will take place next Tuesday, July 28, at 9 am PST.

Tags:, , , ,
Journalist at MultiLingual Magazine | + posts

Jonathan Pyner is a poet, freelance writer, and translator. He has worked as an educator for nearly a decade in the US and Taiwan, and he recently completed a master’s of fine arts in creative writing.

Achieve Better ROI

Related News:


How to integrate cultural distance into your app development

Localization Basics, Technology

It is only natural for a company to focus on its home country when they start developing an app. It’s the market you are most familiar with, and it is where most of your current resources are deployed. However, if you want to continue to grow, and expand the relevance of your app, there may come a time when you need to consider moving into different regions and countries.

More than 5 billion people use mobile services and more than half of those devices are smartphones. When you consider the fact that only a fraction of the world’s smartphone users live in the US, you can see that there is massive potential for growth when you decide to start pushing your app into new markets.

If you are planning to market your app internationally, you have to consider the differences between the people in different markets. Beyond differences in language, people in different places have different cultural values and they respond to messages and imagery in different ways. This is what is known as “cultural distance” and it should be one of your top considerations when developing an app for different regions.


Internationalization is the process of creating an app in such a way that it can be adapted for users in different countries and regions. If you plan to market your app for an international audience, this should be a part of the development process. If you are working with an existing app that was not coded for internationalization, your development team will need to go through the app to separate the content portions of the app from the code that makes the app function.

Along with the internationalization of the app itself, you will need to globalize the efforts your company puts into supporting the application. You will need to look at how you want to position the app in different markets, your advertising efforts, the need for staff in different regions and the potential that there may be legal concerns that come with moving into new markets.


Under ideal conditions, localization will come after internationalization. This way, your app is adaptable for different countries and regions. You’ll be able to make it so things like text and other content can be switched out based on the international market of the user. Not only that, you will have laid the groundwork to move the app into these new markets.

Language is one of the more obvious concerns when it comes to app localization. While English is widely spoken throughout the world, it is not the native language of most people, and most app users prefer an experience that is in their native language.

While it may be tempting to use some type of machine translation, it is recommended that you hire human translators when you localize your app. Some of the machine services do work well, but they are also prone to mistakes. At best, these mistakes will be embarrassing; at worst, they could damage the reputation of your company.

Beyond language, you also need to consider cultural context when localizing an app. This is where cultural distance will play a role in app development.

Accounting for culture

Culture has a significant impact on how people view the world. Translating your app might put the words in the language of your target country, but that does not mean you are sending the same message or speaking to the audience in the most effective way.

Even when translated word for word, some content might have a very different meaning in different places. Obviously, a common turn of phrase in one country might seem like nonsense somewhere else. You also have situations where a translation retains its meaning, but the message might be received negatively in a different culture.

The same is also true for images. An image that evokes positive feelings in one culture might be negative in another. Furthermore, you might have images that work well in one culture, but they just don’t convey any kind of meaning in a new market.

When you are working to localize an app for a new market, you have to think beyond translation. How will the messaging carry over? Will the images have the right impact on the new audience? These cultural differences are important for businesses that want to operate in different countries.

Cultural distance examples

A good example of cultural distance is between those that are individualist as compared with those that are more collectivist. Individualist societies value being self-sufficient and favor the rights and needs of the individual over that of the broader society. In collectivist societies, the group takes priority over the individual and people are more reliant on each other. 

Another example of cultural distance is the acceptance of indulgence. In some societies, people feel freer to express and act on their desires. On the other hand, you have societies that are more restrained. In these societies, people are expected to have more control over their desires. 

These are just two examples of cultural distance, but there are many more that may need to be considered. As you assess a new market, consider the cultural differences and account for them by adapting your messaging and the imagery you use. You may even need to change the way your service functions to account for cultural differences in some places.

As a final tip, keep your eye on things like international downloads, engagement, app analytics, and user feedback. There is a chance your efforts at localization won’t be perfect for some regions. If you notice problems with the analytics, engagement, or user feedback, it can be the first sign that you got something wrong.


Tags:, ,
+ posts

Rae Steinbach is a graduate of Tufts University with a combined international relations and Chinese degree. After spending time living and working abroad in China, she returned to New York City to pursue her career and continue curating quality content. Rae is passionate about travel, food and writing.


Related News:

Localization lessons from a software startup

Localization Technology, Multimedia Translation

When I started working in a startup company as a technical writer, little did I know that in a few short years I would be managing software localizers working on three continents. What I learned in that role makes for an interesting tale and might be helpful to someone in a similar situation. If you are currently working in a startup, or hope to do so one day, please let me share a few things that might be useful to you. MultiLingual‘s issue on startups just went live, so you can check that out as well.

A bit about the company

The company was a survivor of the dot-com bust. Its flagship product was a web-based e-procurement product. There were two kinds of customers — individual corporations and e-commerce exchange sites. The large corporations would install the product on their own servers, and allow their suppliers to respond to request for proposals (RFPs) or participate in reverse auctions — auctions where suppliers tried to secure sales by lowering their prices in competition against other suppliers. The e-commerce exchanges would allow their own customers to do the same on systems that they (the exchanges) maintained.

In the early years, all the customers were based in the United States. The development team was aware that internationalizing the product would be a good idea, but this was certainly not a priority. In the first months of the company’s existence it, after all, was easy to understand why. The technology was new, not widely understood and the payoff from a significant investment was uncertain.

That all changed, of course, once one customer — an e-commerce exchange for mining and oil companies — was eager to pay for user interfaces in Portuguese and Spanish. Internationalization and translation were suddenly spoken of in almost reverent tones by everyone. Around this time, I became involved in the effort, probably because the online help was by far the largest chunk of text requiring translation.

Internationalization issues

While the initial internationalization proceeded smoothly, this simple coding requirement became the source of problems as the product evolved and the code base grew. Sometimes junior engineers or contract employees would forget to externalize strings in this or that module. Errors like these usually led to a reprimand and to reminders that all functionality would eventually be translated.

While these minor mishaps were perhaps excusable in less experienced coders working to meet tight deadlines, that was not the case for other offenses. The most grievous sin against internationalization, for example, was committed by a senior consultant. An audit revealed that he had left over 2,000 error messages embedded in the code. This caused significant delays in translating and testing the product.

No text in image files

One of the mistakes that we made early on was to use literally hundreds of PNG files in the product. At that time, the web was so new that the idea of graphics inserted between text or overlaying text seemed like a great idea. While this strategy made for some attractive web pages, it became a huge burden once we began translating the product.

Fortunately, after one or two rounds of translation, the illustrator found a way to automate the creation of the localized images. Later on, the development team worked to remove text entirely from images and enter it in resource files. While exceptions to this rule were sometimes made in response to a customer request, it was largely respected and helped reduced translation costs.

Customer-specific translations

Even when every string was properly externalized, translated and delivered, it sometimes happened that a customer would want to change previously approved translations for one reason or another. Originally, this was seen as a software problem. A bug report was filed by a field engineer and processed accordingly, eventually getting assigned to localization. Then the original translation was replaced with the requested one.

Since some terms employed in the localized UIs were neologisms, it is not surprising that customers would want to change them as the technology was adopted and the language describing it matured. For some customers, however, opening a ticket and waiting for a patch release was too time-consuming a process to change a text string. They wanted to change translations on their own whenever they saw the need, or in response to criticisms from their suppliers.

In response to this demand, and in response to the growing number of bug reports that were simply language issues, the development team created a tool that allowed authorized users to change localized text interactively. By clicking a text string on the served browser page, an authorized user could enter a new string and save it directly to the localized RESX file. While not every customer decided to use this tool, it did considerably reduce the number of language bugs that were submitted.

localization software exampleIn addition to providing this tool, we adopted a more customer focused approach to translation. This was especially important since in several of the target languages — particularly Slovenian, Turkish and Russian — there were at that time no standard, agreed-upon translation for certain e-procurement terms. In the case of Slovenian, for example, the translator discovered that he was first to introduce several terms into the language by working directly with the customer who had demanded this language.

Updating resource files

As noted above, many of the customers were large corporations and drove development of customer-specific functionality. This led to custom resource files in addition to standard resource files. Their demands often led to features that were incorporated into the main product.

In the early days, when there was just one customer that wanted the user interface translated into Spanish and Portuguese, updating the standard and custom resource files was a relatively easy task. Over time, as the number of supported languages grew, and as the number of customers grew maintaining and updating the resource files became a full-time task.

It was necessary to create a tool that would compare the English resource files — both base and custom ones — with the localized resource files in order to extract the strings requiring translation. Once those strings were translated, the tool would need to re-integrate them into the existing localized resource files.

We looked for an off-the-shelf software package that could do this, but at the time there were none that met our needs. Happily enough, an engineer volunteered to create a Java-based utility that performed all these tasks remarkably well. Since the number of resources eventually swelled to over 12,000, you can imagine that this utility was essential.

Figure 2 shows the translation update workflow. As shown below, the tool performed two separate comparisons in order to generate a delta or diff file containing the strings to be translated. It compared the current English resource file to the previously translated resource file to capture the resource strings that had been added. Then it compared the strings in the current English resource file to the strings in the previously translated file to see if any of the strings had changed. Then it compared the English files against each of the localized resource files in order to determine which strings needed to be added, deleted or modified for each language.

The diff files containing the new and modified strings were sent out for translation. The agency translators used translation memory from previous assignments to translate the strings. After delivery, the translation tool integrated the newly translated diffs into the existing translated resource files.

localization software

Lowering translation costs

While this tool worked well from a technical perspective, the turnaround for agency translations was often slow, or at least too slow for some of our customers. Each translation job required a quote, and each quote required approval. The lag between initial quote request and delivered translations could sometimes exceed eight business days, even for a relatively small translation job.

Delays such as this and the relatively high cost of agency translations did not escape the attention of upper management. One of the conditions of profit maximization is cost minimization and the CFOs of startup companies are acutely aware of this. The end result for localization was constant pressure to lower translation costs.

One of the more interesting attempts at doing this involved the creation of a localization group based in India. The startup, which had by then become profitable, bought a small Indian company that had useful industry data. The CEO of this company had on occasion hired locally based translators for short-term assignments. He suggested that we do the same.

I hesitated at first, knowing from experience how complicated it was to translate the user interface and online help. At the insistence of upper management, however, I slowly assembled a team of translators. This team consisted mostly of expatriates who were living in India for various reasons.

Since these recruits were largely new to professional translation, we organized training for them both on our software products and on the various tools that we used in-house. While few had had previous exposure to software development, most were able to learn enough to adapt to the demands of the job.

After the initial ramp up, we were able to lower translation costs and speed up translation turnaround. This was possible because the translation memories built up from earlier rounds of translation enabled the team to leverage existing translations when formulating new ones. This strategy worked especially well when the remote translators worked on software updates.

The takeaway

If you should find yourself responsible for localization in a startup company, there are four things that you are likely to encounter:

  • A lack of knowledge of internationalization
  • Coding lapses on the part of the development team
  • Customer concerns such as complaints about translated strings
  • A persistent demand to lower translation costs

To deal with these issues, it would be best to employ the following strategies:

  • Explain whatever needs explaining to whomever
  • Remind development managers to enforce internationalization coding standards
  • Remember that the customer is king
  • Defend the need for quality translation but be open to new approaches, whether technological or labor-related
  • Have fun — so many people would relish the chance to do what you do

Kevin Donovan has worked in localization for over 15 years. He has managed translation teams working on healthcare and business (B2B) software. He has also written articles for the Wall Street Journal and Computer Graphics World.

Related News:

Localization Unconference: The First 10 Years

Language Industry News and Events

Localization Unconference (#LocUnconf) is 10 years old tomorrow!

The first Localization Unconference was hosted March 14, 2008 in Silicon Valley at Saleforce’s San Mateo location.

The original and first localization unconference logo from 2008

The original and first localization unconference logo from 2008

Unconference Strong

I am delighted to say that the event is still going strong and is now worldwide; organized by and attended by people interested in localization and related areas of our industry who want to meet and make connections by discussing hot topics or things that normally don’t get on the regular conference circuit agenda.

I can see from the Localization Unconference website now, for example, that there are already events planned for Toronto and Berlin in 2018. There have been many other events all over the world since 2008.

And, of course, the event is now part and parcel of the regular Localization World agenda. All thanks to an awesome team of passionate organizers driving it forward.

Guinness: Inspiration for the Unconference

I was inspired initially to reach out to others from a localization-related unconference section of Mashup Camp when it was held in Dublin’s Guinness Brewery in 2007. I blogged about my thoughts on MultiLingual’s blog (or Blogos as it was known then) and put the idea out there. The original blog is still there!

I’m indebted especially to Shawna Wolverton of Salesforce who also saw this opportunity to innovate a little bit in the localization meetup space and drove these sparks of ideas forward into the first event. That was a success but the event also later spread worldwide, mostly organized by locally-based, different volunteers.

Incidentally, I still have the 2007 Apple MacBook Pro 2.2 GHz 15-inch Core 2 Duo that I used at Mashup Camp (and shown in the blog post) and at the first Localization Unconference. Go different badges but they wear them just the same, as Aztec Camera would say.

Apple MacBook Pro from Mashup Camp and Localization Unconference still working!

My 2007 Apple MacBook Pro from Mashup Camp and Localization Unconference is still working! Those laptop stickers are upgraded regularly!

I also still have the original lunch voucher from the Salesforce-hosted event. I guess I didn’t eat at the event (I brought donuts from Chuck’s in Belmont, San Mateo if I recall correctly) with all the excitement.

Original Localization Unconference Lunch Voucher from Salesforce

Original Localization Unconference lunch voucher from Salesforce

I wonder is that voucher is still good for one lunch?

Whatever. The Localization Unconference is good for a lot more than one!

The next 10 years

So, here’s to more Localization Unconferences. And here’s to the power of the localization community, its volunteers, participants and the idea of self-enablement.

Stay tuned to the Localization Unconference website for more information and to MultiLingual Insights for reports on happenings, past and present.

Tags:, , , , , , , , , ,
+ posts

Ultan Ó Broin (@localization), is an independent UX consultant. With three decades of UX and L10n experience and outreach, he specializes in helping people ensure their global digital transformation makes sense culturally and also reflects how users behave locally.

Any views expressed are his own. Especially the ones you agree with.

Related News:

Language at the ❤ of Conversational Interfaces

Personalization and Design, Translation Technology

A Chat About Language and UI

Robotspeak in San Francisco. A great store, but it’s also exactly how conversational interfaces should NOT sound: like a robot. Conversational interfaces offer a natural way to deal with a multitude of digital asks and tasks and the crafting of language is critical to that intent. (Image by Ultan Ó Broin)

Robotspeak in San Francisco. A great store, but it’s also exactly how conversational interfaces should NOT sound: like a robot. Conversational interfaces offer a natural way to deal with a multitude of digital asks and tasks and the crafting of language is critical to that intent. (Image by Ultan Ó Broin)

Chatbots and conversational interfaces are all the rage right with startups, VCs, innovators and users alike. Messenger apps have surpassed social media in terms of popularity and we’re witnessing the awesome agency of chatbots such as KLM Messenger as a natural way for users to perform a huge range of digital asks and tasks without the need for special devices or apps.

Going Global With Conversational Interfaces

But what are the localization and translation aspects to chatbots and conversational computing?

To a large extent, the natural language processing (NLP) backend capabilities of the bot or messaging platform determine much of the linguistic side of the user experience (UX). However, there are plenty of other considerations for internationalization and localization people to concern themselves with, not least educating designers and developers in globalization best practices.

Check out this super article “Do you want your chatbot converse in foreign languages? My learnings from bot devs” by Artem Nedrya for a start.

It is also very clear that there is a huge role for the conversational UI writer in the design and creation of conversational interfaces. An understanding of language, its style, tone, grammar, and so on, is central to making or breaking a conversational interface UX but also to ensuring that any content created is localizable and makes sense to a local user.

Here’s an article I wrote for Chatbots Magazine that covers the topic of language and chatbot UX that also touches the translation space. I hope you find my thoughts in “Writing Skills: At the ❤️ Of Chatbot UX Design” useful.

Conversational UI is dependent on bot and messenger platform NLP capability but human language skills are still definitely at the core of conversational UI design. (Image by Ultan Ó Broin)

Conversational UI is dependent on bot and messenger platform NLP capability. But human language skills are still definitely at the core of conversational UI design. (Image by Ultan Ó Broin)

Don’t be surprised if you see the topics of chatbots and conversational interfaces coming up on the agendas of localization conferences and in publications a lot more!

As ever, for a conversation on this blog post, find the comments box!

Tags:, , , , , , ,
+ posts

Ultan Ó Broin (@localization), is an independent UX consultant. With three decades of UX and L10n experience and outreach, he specializes in helping people ensure their global digital transformation makes sense culturally and also reflects how users behave locally.

Any views expressed are his own. Especially the ones you agree with.

Related News: