DEV Community: Julia Herasymchuk

How to Localize your SaaS Application: Best Practices

Julia Herasymchuk — Tue, 27 Dec 2022 16:51:44 +0000

As a SaaS business grows, it becomes more important for you to make your product available to users all over the world. As more and more customers from different locales come in, you might start to wonder how to tackle SaaS localization and translation without creating extra work or complicating the processes that already work.

No matter how much content you have and how many people are creating and editing it, with the proper infrastructure and tools, it is possible to create a multilingual product that will help you win customers speaking different languages and grow your business. Translation and localization can be automated, so there’s no copy-pasting for you.

This article will cover all you need to know about localizing SaaS applications and how to do it with Crowdin.

What Is SaaS?

Simply put, SaaS products can be accessed via the Internet instead of being installed on your machine. This makes software much more accessible to a broader range of users.

Why Should You Localize Your SAAS Application?

Software as a service (SaaS), also called on-demand software or cloud-based software, has become very popular and is used by many big and small businesses. Most SaaS companies use English as a primary language for their products. Since not all customers speak English as their first language, they want to use SaaS apps in the language they prefer. This is what drives the discussion about localization.

Let’s talk about how localizing SaaS can help your company.

Remove language barriers to improve user activation

Language, and cultural barriers can make it hard for your SaaS product to reach users in other countries with the same success as solutions available in the local language.

Localization lets you communicate better with your customers and stay close to them. The first steps in introducing users to your product are a localized website and user interface. To improve the onboarding process, you can localize the onboarding messages and emails to guide customers through your product in their language.

Build trust and better relationships with customers to reduce churn
When done right, localization is a great way to win the trust of local customers and get more people to use your product or service in local markets.

If people are already using your product, it’s your task to keep them happy. At this point, you can provide support in their native language. This includes help articles and blog translations. You can also create multilingual chatbots or implement live chat translation. This way, your current customers will feel cared for, and you’ll be able to build a stronger relationship.

Stand out from your competition: gain a competitive edge

Typically, when choosing a product, people test several solutions. They start a free trial, watch demos, and review your website content. Make your product stand out by making it available in your customers’ language. Soon, providing a product in several languages might not be an advantage, but it will be something users will expect by default, so start preparing now.

Localizing for local languages also gives companies a competitive edge because you can communicate with locals better and get them to use your product even if they don’t speak the source language of your product.

Spend less (and boost your revenue)

If you localize your SaaS product, you can make much more money. The more markets you go into, the higher your profit margins can get.

But you can only get all of these benefits if you use the best SaaS localization practices. We’ll discuss this later in the article, but let’s look at one example.

Such a simple thing as reviewing content before localization, or even better, writing content with localization in mind, can save you a lot of money. This way, you can ensure you’re not translating duplicate content or confusing translators with typos in the source text.

Writing for international markets has its own rules. Writing in plain, straightforward language is better in an active voice. This way, it’s clear for translators how to convey your message. If you avoid ambiguity, it will take you less time to separate pieces of content, which will speed up the process.

What to Consider before You Start Localization

Once you decide it’s time to reach new markets and improve conversions in the ones where you’re already present, you should create a plan for your localization initiative. As it might be tempting to localize into as many languages as possible immediately, we recommend setting your priorities before diving into this adventure.

Here’s a list of things to consider before you start your localization project:

Choose the markets you want to target

There are at least two ways to start:

You can enter entirely new markets where you have no customers yet. This would definitely take more time and effort, but results in the form of revenue can also be great.

Or you can see where your product is already present, but the conversion rates are not what you want. This way, you already have some data to which you can compare your results.

You need to choose specific locales and translate the text carefully. For example, if you have a big market in China or Japan, it makes sense to put Chinese and Japanese translations at the top of your list.

Here are some strategies you can consider for choosing target languages:

Leverage Google Analytics data. You can check which languages are the most common among your website visitors and bring you the most traffic.
If you’re using universal Google Analytics, go to Audience > Geo > Language. You can also filter by Bounce rate using the same report to see for which languages it’s the highest, so you know these people leave your website and don’t see their language on it.

You can run a survey in the UI or on your social media, asking your users which language they expect the most. It might not be the most accurate way, but it’s definitely a quick way to get answers.

Market research. If your analytics team has already decided which markets you’re targeting - what is left is to choose the most common languages there and start your project.

Choosing what to translate

First, you must decide what and how you want to translate. Text is still the best option, but you could also localize pictures or videos. This would be a big plus because it would show that you have a unified approach to localization. It would be easier to update the translations if the service offered content made on the spot and pulled from an API.

Make sure that as many translation strings as possible are taken care of. It wouldn’t make sense to have translations that aren’t quite right or are missing in many places, like buttons, labels, or modal messages. A translation management system can help keep track of messages that need to be translated.

What type of content to localize in the SaaS product:

Website
Global SEO (Search Engine Optimization)
Blog and help articles
Email marketing campaigns
Make adaptable design
Text on pictures and video subtitles
Chatbots and live chats.

Read more in our previous article about how to make your product multilingual to increase your multilingual marketing strategy, and localize each type of content with the help of Crowdin.

Organizing a translation team

All parties involved in the localization process should be in sync with each other. For example, you need a localization manager who is in charge and has the final say on software requirements and technology decisions.

You can invite translators and proofreaders you already work with to your organization or project. These could be

In-house translators
Freelancers
Translators from the translation agencies you already work with
Crowdin’s translation agency partners
MT
Communities

Crowdin Enterprise makes it easy to combine different approaches because each project has its workflow. Each workflow step can be given to a different person or vendor so they can work independently. Depending on the type of content or product you want to localize, you can use different methods to translate it.

You don’t have time to hire someone to translate the content of your software. Crowdin Language Services lets you order translations with just a few clicks.

Investing in software for localization

Last but not least, another SaaS provider can help you with localization needs. This means you can buy specialized software to speed up the localization process and meet your needs as you go. For example, you might have only a few tasks in your plan. As your business grows, you may need to change your plan to include project management, integration with other systems, a translation memory, etc.

Localization software enables businesses to centralize and automate their translation and localization workflows.

In short, localization software includes things like

A cloud-based shared workspace for all parties.
Notifications for stakeholders about changes in the status of software localization.
Support for all common file types.
Software development kits or APIs are used to connect to the company’s existing systems.
Software strings can be quickly and automatically imported from code repositories and exported when localization is done.
Ability to look at translations of software before putting them online.
Statistics about how well the software is localized.
Keeping track of terms.
Checks for quality assurance.

UI strings that need to be translated could have visual references.

The ability to translate content by machine.
On the surface, there seem to be a lot of different SaaS (software as a service) localization solutions on the market. However, not all localization software is created equal. Some are made with translators and their needs in mind, while others are made for developers or UX designers.

But if you want great multilingual content, choose the universal all-in-one solution for localization, like Crowdin, which is easy for everyone on the team, including the product manager, developers, translators, decision-makers, and others. Also, make sure it meets your business goals and quality standards.

Learn the key steps for the SaaS localization with the help of Crowdin.

Best Practices of SaaS localization with Crowdin

Now that you have your list of priorities and are ready to start translating, you need to prepare. Here are the most critical steps to reaching that goal with the help of Crowdin:

Automate localization

The best way to save time is through localization automation. A localization management platform like Crowdin helps you automate processes. Crowdin has over 450 apps and integrations that allow you to connect all of your tools to the content, send sources to Crowdin, and receive automatic translations back into your tools without copying and pasting. So, translators always have access to new content, and you get translations into the system, where you create content.

Connect to the tools you already use
Crowdin offers integrations with tools for localizing different content for your SaaS product, there are integrations in such categories as:

CMS
Marketing
eCommerce
Development
Design
File Management & Storage
Customer Service
Machine Translation
TM & Glossaries
File Formats
Translator Productivity
Manager Productivity
Team Chat & Notifications
Task Management
Gaming

If you use Crowdin Apps to connect all the tools you need, you can set up continuous localization processes for any content you need to translate. Websites, blogs, onboarding materials, how-to articles, social media campaigns, and much more. SaaS localization might seem hard, but if you make a plan with the right tools and resources, it could help your business for a long time.

Provide translators with productivity tools
Translators can work on Crowdin in the Editor. The Editor gathers all the information the translation teams might need while working on the content. MT and TM engines’ suggestions, comments, search, filters, context, file preview, and terminology are all in one place. In addition to the usual features, you can add apps from the Store to the Crowdin Editor to make it more powerful.

Give more context for the better quality of the translation

Whether you do the translation yourself or hire a team, the quality of the translation will depend on how good the team is. Still, even the best translators might get the sources wrong if they don’t have enough background information.

When you set up a localization project, you shouldn’t skip the step of providing context. Crowdin gives you several ways to explain the context of a translation.
In Crowdin, translators work in the Online Editor. Along with fields for the source and translated content, there is a field with the context added from the comments to each string in the codebase.

Also, if any screenshots you uploaded had a string tag, the screenshot will be shown next to the source string. Find out more about how you can use screenshots to localize applications.

Run QA checks to ensure your translations are correct

Have a team of testers do both automated and manual localization testing to ensure everything is going well. Tell them to look for unusual situations when the text is too long, has memorable characters, finds the correct locale, and the images load correctly. Check to see if the text is shown slowly or if it flickers. You should also see if the currency and number formats suit the target region. For auditing, they need to report all the necessary test cases.

One of the last steps in the translation process is usually proofreading. Once the translation is done, a proofreader can look over the text to find any mistakes and fix them. You can turn on Quality Assurance checks that help you make sure your translations are correct, precise, and free of mistakes to make things easier.

Try automation of localization to speed up the process

A lot of automation and continuous delivery are used in the SaaS model of agile application development. For your translation pipeline to be agile, you must add tasks and events that help you deliver the final product. Things like version control, git-ops, chat-ops, and webhooks can help you get ahead of the competition in a big way.

Continuous localization makes sure that the localization process and the development process are both going at the same time. The localization software automatically finds new and changed strings and sends them when they are ready to be merged and published. It makes your localization workflow more efficient and gives you more options.

Learn how continuous localization can benefit each team in our FREE e-book. It includes our own experience and thoughts about this approach for each department, as well as the thoughts of more than 10 experts in the localization field.

If you want to find a good technology vendor to help you translate your SaaS content, you can:

Sign up for Crowdin’s free trial to see how the platform works.
Book a Demo with one of our experts and get answers to all your questions to make localization easier.
Watch a recorded on-demand demo whenever you want to learn about the platform’s main features.

Wrapping It Up

Since SaaS companies work well across borders, anyone on the planet should be able to get in touch with your company. The main difference between companies that offer localization and those that don’t is that the latter don’t have a strategic plan for making their user base accessible to everyone. This happens more often with essential services, where the choice of words depends on the area. By giving your users content that is more relevant to their needs, you give your SaaS platform a significant advantage over the competition and make it more credible.

Java i18n (Internationalization) and Localization Tutorial

Julia Herasymchuk — Fri, 02 Sep 2022 08:46:04 +0000

As an aspiring developer, finding a quick and reliable way to offer your app to the world can be challenging. It is the reason why you have to learn Java i18n and l10n (internationalization and localization).

Using Java, you already have the tools to detect the user’s locale and translate your app accordingly.

Java Internationalization Is an Important Part of the Development

Internationalization happens at the development stage, and the sooner it’s implemented – the fewer code changes would be required. However, there are some myths about i18n that we’d like to debunk:

Internalization is only about translating the text.
It is challenging to implement it, and the process is burdensome.
Only the project architect has to think about it.

As you might have guessed - these are all false statements. While localization is relatively simple to code even for a junior developer, many bundles and libraries provide ways to translate text from your app and make it culturally correct – this may include date formats, standards of measurement, or even the whole UI design.

But is it demanding to create a new structure for your application? Nobody likes to go back to their code and rewrite everything repeatedly. An agile approach to software development teaches us to implement everything step-by-step, so the best case scenario is to build your project with internalization in mind.

Let’s imagine the process like this:

You create an application.
The app reads the user’s locale and formats, dates and numbers.
It then takes text data from the pre-defined resource and outputs the correct language to the user of our app.

So there must be ways to store all your important messages in one place - you could translate them yourself or automate content updates using a convenient service such as Crowdin.

With Crowdin, you can localize any git branches you want, or you can use CLI/API integrations. Read more life hacks on app translation.

How to Implement Internalization in Java

Java is a powerful programming language that provides convenient ways to work with multi-lingual resources. The best way to do it is what’s called a ResourceBundle.

ResourceBundle Class

ResourceBundle, together with Locale, are the fundamentals of internalization in Java. ResourceBundle class is used to read strings from text files (.properties).

Imagine you could store all your Strings in one file, and the translators do the rest. That’s the job of the .properties file. Every single .properties file serves strings for each locale that your application supports.

Properties usually have a standard naming:


<ResouceBundleName>_<language_code>_<country_code>

for example, MessageBundle_uk_UA for new ResouceBundle

MessageBundle.properties is the source language file

And the strings inside are organized like this:


menu.addCity = Add a new visited city.

menu.chooseAction = Choose an action:

menu.removeCity = Remove city from the tracker.

menu.changeLocale = Change the localization of the app.

menu.exit = Exit the app.

menu.editCity = Edit an existing city.

We should organize all the strings into categories and be clear with their names. When we want to get the string - on the right - in our Java app, we call it using its name - on the left.

Getting Locales List in Java

You may wonder - “I have already created a Resource Bundle, can I assign it to a Locale?” - Yes! That’s where we use the Locale class.

It provides ways to interact with the user’s system, such as using these methods:


-> returns user’s default locale.

Using the system’s default localization on the app’s startup is a good practice. This method provides the user’s default locale, which you can use to load strings from ResourceBundle without the user even thinking about it.



```(String language_tag)```

 -> returns Locale for the language.

As you have already noticed, each Resource Bundle can be created for specific language tags. Sometimes you may need to differentiate between Australian English (en_AU) and American English (en_US) - so you can specify it using this method.



 ```(Locale.getAvailableLocales()```

-> returns an array of all installed locales.

We use this method when we want to know which locales are installed on the user’s JVM. You parse the list - you know what to serve to the user.

### Dates and Numbers

As I mentioned earlier, different countries may have different ways of presenting Dates and Numbers. Let's assume we have 1 million. In English, it should be formatted as 1,000,000; however, in German, it should be 1.000.000.

To format numbers, Locale-aware creates an instance of NumberFormat class:

NumberFormat nf_en = NumberFormat.getInstance(Locale.ENGLISH);

String number_en = nf_en.format(1000000);




-> 1,000,000

NumberFormat nf_ge = NumberFormat.getInstance(Locale.GERMAN);

String number_ge = nf_ge.format(1000000);




-> 1.000.000

Same thing for dates. To format a date in Java, all you need to do is create an instance of DateFormat class:

DateFormat df_en = DateFormat.getDateInstance(DateFormat.MEDIUM, Locale.ENGLISH);

String date_en = df_en.format(new Date());




-> Aug 7, 2022

DateFormat df_ge = DateFormat.getDateInstance(DateFormat.MEDIUM, Locale.GERMAN);

String date_ge = df_ge.format(new Date());




-> 07.08.2022

The best part is instead of hard-coding the locale, we can use the user’s locale to format everything according to their culture!


## Context

So, you build the app and have all strings in English. Here’s the time you invite translators to your project. A lot of different people will look at the strings you wrote. How to build our resources so they will be translatable?

The concept of context plays a huge role in localization. Without it, some text may be translated poorly, but not because of the translator. Complex resources must have context attached!

If you name a string “string1,” - the translator will have no idea what this string’s for. Here’s a <a href="https://blog.crowdin.com/2019/11/05/no-context-no-quality-give-translators-context-to-get-better-translations/" target="_blank">little reading material</a>
 on why it’s crucial.

Long story short: be sure to correctly name all your strings in the .properties files so that people can know the context of it.


## Java i18n Application Example

We have talked about internalization only in theory. Let’s get to the point with our tutorial, where we will use all our new knowledge.

This tutorial will help to create a light Java project and implement internalization. All the project files will be available to fork <a href="https://github.com/danielsutts/i18n-with-Crowdin" target="_blank">here</a>.

### App Overview:

Our application is a small city visit tracker. I’ll call it simple - City Visit Tracker. The user enters their name and is presented with a few actions:

1.  Add a new city to the list.   
2.  Remove a city from the list.
3.  Edit an already added city (we all had this problem remembering the dates, didn’t we?).    
4.  Change the localization of the app.
5.  And, finally, exit the app.

I will use <a href="https://crowdin.com/on-demand-demo" target="_blank">Crowdin</a> for the translation of my resources. Using Crowdin - later in the tutorial.

First things first, let’s define the Client class.



```javascript

public class Client {
   private Locale userLocale;
   private final String username;
   private Map<City, Date> visitedCities;
   public Client(Locale userLocale, String username) {
       this.userLocale = userLocale;
       this.username = username;
   }
   public Locale getUserLocale() {
       return userLocale;
   }
   public void setUserLocale(Locale userLocale) {
       this.userLocale = userLocale;
   }
   public String getUsername() {
       return username;
   }  
   public void addCity(City city, Date dateVisited) {
       this.visitedCities.put(city, dateVisited);
   }
   public void removeCity(City city, Date dateVisited) {
       this.visitedCities.remove(city, dateVisited);
   }
}

We want our user class to store all the cities visited, the user’s name and, most importantly, the user’s preferred locale. I’ve also added Getters and Setters so we can change the info to our needs.

Next, let’s define the City class.


public class City {
   private final Locale cityLocale;
   private final String cityName;
   private final String cityCountry;
   public City(Locale cityLocale, String cityName, String cityCountry) {
       this.cityLocale = cityLocale;
       this.cityName = cityName;
       this.cityCountry = cityCountry;
   }
}

Since we’re allowing the user to put their cities to the list, let’s add all the cityLocale properties to the class, so we could even add the feature to translate city names in the future if we need to.

Resources

Let’s create a new folder with the Message Bundle name and add a few .properties files. I want my app to have English, Polish, and Ukrainian. Therefore, I’m adding four files to the folder (the fourth one is the default).

MessageBundle/

/MessageBundle.properties

/MessageBundle_en_US.properties

/MessageBundle_pl_PL.properties

/MessageBundle_uk_UA.properties

For the sake of simplicity, we will not use the default file now, and I will start populating the resources in the en_US bundle.

So, what do we want in our Resource Bundle?

We need some menu messages:


menu.printAll = Print all cities.

menu.addCity = Add a new visited city.

menu.chooseAction = Choose an action:

menu.removeCity = Remove city from the tracker.

menu.changeLocale = Change the localization of the app.

menu.exit = Exit the app.

menu.editCity = Edit an existing city.

We want some basic words that we might use:


word.yes = Yes

word.no = No

word.city = City

word.date = Date

And here are all the messages we are going to use in our application:

message.welcome = Welcome to City Visit Tracker!

message.hello = Hello,

message.enterYourName = Enter your name:

message.addCity = Add a new city!

message.addCityName = Enter the city name:

message.addCityDate = Enter the city visited date

message.saved = Successfully saved a new city!

message.cityDeleted = Successfully deleted a city!

message.cityEdited = Successfully edited a city!

message.forExample = for example:

message.noChanges = No changes will be applied.

message.chooseLocale = Choose one of available languages:

message.tryAgain = Try again.

message.noCities = No cities saved yet!

message.chooseDelete = Choose a city to delete.

message.chooseEdit = Choose a city to edit.

message.newCityName = Enter a new city name

message.newCityDate = Enter a new city visited date

Crowdin and Resources

I added all the messages we needed. However, when developing an application, you want it to be Agile. Crowdin’s Github integration is available. I will go through integration.

Go to your Crowdin account and sign in.
Open a new project.
Enter the info about your project.
Choose the Source language and Target languages (in our case, the source is English, and the target is Ukrainian and Polish.
Select “Choose integration” in your main menu -> GitHub Personal -> Authorize it with GitHub.
Choose a repository you want to work with and select the branch.
You want to create a configuration file in your repository, where you need to specify the /src/resources folder for source files.
You also want to specify the translated files folder. That way, your translators can give out their work piece-by-piece without needing to touch Git. Isn't it cool?

The next step is to hire professionals to translate your text. But one more excellent feature of Crowdin allows us to translate our source files manually! Let’s do just that.

Go to Home - choose target language - press Translate. Now you should see Crowdin’s UI that allows you to choose the most appropriate translation of the Strings in our Source file.
Go through them and choose Suggestions below (by the way, they are pretty good!).
Once you’ve reached the end of both Ukrainian and Polish files, go back, and press Proofread to approve the translations. (this is usually a task of the localization director, so don’t be afraid to do it now - it’s only for practice :)
In your Home folder, press “Build & Download” to download the translations you've just created. Now you can copy them into your folder and use them as custom internationalization of your application!

Let’s Go On with Our Application

We want our application to write, edit and remove cities. We also want it to list all the cities we’ve already added.

With the use of DateFormat, ResourceBundle and Locale Java classes, let’s add these methods to our main class:

To change the app’s locale, we simply print the user list of locales and try loading it from our ResourceBundle.


private static void changeLocale() {   System.out.println(userResourceBundle.getString("message.chooseLocale"));
   System.out.println(Arrays.toString(locales));
   Scanner scanner = new Scanner(System.in);
   String newLocale = scanner.nextLine();
   try {
       userResourceBundle = ResourceBundle.getBundle("resources/MessageBundle", new Locale(newLocale));
   } catch (MissingResourceException e) {
      System.out.println(userResourceBundle.getString("message.tryAgain"));
       changeLocale();
   }
}

Next, we provide the user with the menu and wait for the input. Here you see only a few methods. Visit the app’s GitHub page for more.


private static void menu() {
   Scanner scanner = new Scanner(System.in);
   // Print out the menu
   System.out.println(userResourceBundle.getString("menu.chooseAction"));
   System.out.println("0 - " + userResourceBundle.getString("menu.printAll"));
   System.out.println("1 - " + userResourceBundle.getString("menu.addCity"));
   System.out.println("2 - " + userResourceBundle.getString("menu.removeCity"));
   System.out.println("3 - " + userResourceBundle.getString("menu.editCity"));
   System.out.println("4 - " + userResourceBundle.getString("menu.changeLocale"));
   System.out.println("5 - " + userResourceBundle.getString("menu.exit"));
   String answer = scanner.nextLine();
…
   // If Menu Action is "Add City"
   if (answer.equals("1")) {
       try{
           addCity();
       } catch (Exception ex) {
     System.out.println(userResourceBundle.getString("message.noChanges"));       System.out.println(userResourceBundle.getString("message.tryAgain"));
       }
       menu();
   }


…

Here we define the addCity() method that adds city to our user’s repo. As you can see here, we use all the power of ResourceBundle, DateFormats and Locales to give the user the most authentic and internationalized experience.


private static void addCity() throws ParseException {
   // Take user's input
   // Create a new City instance to fill it in
   Scanner scanner = new Scanner(System.in);
   City newCity = new City();
   // Add the user's locale to the City instance
   newCity.setCityLocale(userResourceBundle.getLocale());
   // Print out the city name prompt and set the new name
   System.out.println(userResourceBundle.getString("message.addCity"));
   System.out.print(userResourceBundle.getString("message.addCityName"));
   newCity.setCityName(scanner.nextLine());
   // Print out the date prompt and set the new date
   System.out.print(userResourceBundle.getString("message.addCityDate") + ' ');
   // Here, we transform the input data according to the user's locale
   // and save it as usual Date class
   DateFormat df = DateFormat.getDateInstance(DateFormat.DEFAULT, userResourceBundle.getLocale());
   System.out.println('(' + userResourceBundle.getString("message.forExample") + ' ' + pdf.format(new Date()) + ')');
   Date newDate = df.parse(scanner.nextLine());
   newCity.setVisitedDate(newDate);
   repo.addCity(newCity);
   // Tell user we saved a new city!
   System.out.println(userResourceBundle.getString("message.saved"));
}

Let’s define our pinnacle - the primary method of City Visit Tracker!

We’ll have to define three static variables in the CityApplication.java file:


protected static ResourceBundle userResourceBundle;

private static final String[] locales = new String[]{"en_US", "pl_PL", "uk_UA"};

private static final CityRepository repo = new CityRepository();

ResourceBundle helps us switch between different l10n bundles. Locales tell us which languages are supported by our app. Repo is initialized to store the cities.

From now on, all I need to do on the app’s startup is get the user’s default locale, print some welcome messages and start the menu() method.


public static void main(String[] args) {
   // Get user's default locale
   // Load ResourceBundle for the locale
   Locale locale = Locale.getDefault();
   userResourceBundle = ResourceBundle.getBundle("resources/MessageBundle", locale);

   Scanner scanner = new Scanner(System.in);
   System.out.println(userResourceBundle.getString("message.welcome"));
   System.out.print(userResourceBundle.getString("message.enterYourName") + ' ');

   String name = scanner.nextLine();
   Client client = new Client(locale, name);

   System.out.println(userResourceBundle.getString("message.hello") + ' ' + client.getUsername() + "!");

   menu();
}

And we’re done. Now is your turn! This app is a small example of what you can do with Java’s i18n and l10n bundles.

Conclusion

In this tutorial, we discovered what Java offers us in terms of localization and internationalization of our applications. I18n and l10n are extremely important when you want to provide the absolute best experience to the user.

ResourceBundle class gives us an easy way to work with resources.

Locale class gives us ways to interact with the user’s locale.

DateFormat and NumberFormat allow us to format dates and numbers for the user’s locale.

Don’t forget to make your translations agile and clean. Create a default package and let the translators and proofreaders do the work. We’ve also explored a way to automate the translation process with Crowdin – as you can see, it’s simple and fast.

Android App Localization: Key Steps

Julia Herasymchuk — Thu, 11 Aug 2022 13:33:00 +0000

You might be a beginner developer making your first Android app or an experienced programmer adding to your dozen or so other Android apps. But the main question is: who are you making this app for? This article will help you learn the key steps for the localization of Android applications and reaching new markets.

Reasons to Localize Your Android App

A leading media and information brand for the app industry, Business of Apps, says that Android is the most popular operating system in the world, with more than 2.5 billion active users in more than 190 countries. That is why Android apps are used by many people worldwide, so getting Android localization right has become an essential part of creating mobile apps. Localization of Android apps is the process of adapting a mobile app for people who speak different languages or live in different countries.

You probably want your app to grow and be used by more people than just those in your local area. You want it to reach people on other continents and eventually go global. The problem is that not everyone speaks English. You will need to support more than one language sooner or later. It is an excellent reason to think about adding localization support to your Android app from the beginning.

Localization can also be a part of app store optimization processes as a separate step for improving the visibility of your app. App localization is a lot about translation, but it's not the only thing. Localization includes a full review of how an app works to ensure it works well in each locale. Localizing app descriptions in the Google Play app stores is also essential for worldwide app store optimization (ASO).

Even though localization takes time and work, it pays off in terms of downloads, new users, and money. A study by Distomo found that localized apps had 128% more downloads from the app store than apps that were not localized. Also, localized apps brought in 26 percent more money in each region. These numbers show that localizing your Android apps for a global audience is a great idea.

Main Steps for Android App Localization

By following best practices, you can make the process of localizing cheaper and less time-consuming while also making it easy to scale and maintain.

Prioritize locales and languages you’ll begin with

When localizing Android apps, the most crucial choice is which markets to focus on. There is a cost to making your app work in a particular place. So, you shouldn't just try to make your Android app work in every language because you can.

Also, the cost of making your app work in a different language is not the same in every case. It would help to consider how much money you will get back.

Focus on the most common languages on the internet to get started. There are the five most-used languages on the internet. In order, the most common languages are English (25%), Chinese (19.8%), Spanish (8%), Arabic (4%) and Portuguese (4%).

The three languages – English, Chinese, and Spanish – make up 55% of all the content on the internet, so they should be the first ones to be localized. When you are done localizing for these languages, you can move on to the next one.

Make layouts with localization in mind

Different languages need different lengths for texts. When designing your app’s UI, you should consider how text grows and shrinks in different languages. It's typically recommended that UI elements have 30% more space in other languages.

There are three main rules of design you should stick to

You shouldn't give UI elements fixed widths and heights (buttons, text fields, menus, labels, images). If not, when texts are translated into other languages, they might be cut off or have too many spaces.
You should put elements together in a way that makes sense. And put them in the same place every time. They need to be rearranged to make sense in the new languages. For example, if you have some numbered instructions on an Android app with buttons or other UI elements.
Containers and wrappers should be able to change their sizes to fit the things they hold. A container can contain, for example, 3 buttons (you can find “ViewGroup” in the Android documentation). If the text is longer on another locale, then this container must correctly display the same 3 buttons without covering anything else.

If you need to rearrange your layout to fit a specific language, you can create an alternative layout for that language (for example, res/layout-de/main.xml). However, doing this can make your app harder to maintain. It is better to create a single layout that is more flexible.

Think about languages written and read from right to left

Some languages are written and read from right to left. Hebrew and Arabic are good examples. You need to make layouts that can be turned around if necessary. It could be an expensive process that must go through many steps. That's why it's essential to think carefully about which languages you want to support before you start developing. Most of the time, modular design is thought to be the best way to go in this situation.

Word wrappers and line breakers

How words are split up is another crucial difference between languages. Even though space is used to separate words in many western languages, East Asian languages like Chinese and Japanese don't use spaces to do this.

Consider the last example:

English: You should localize your Android app.

Chinese: 您應該本地化您的 Android 應用程序 (Disclaimer: it's text from Google Translate, I can't guarantee the accuracy of this translation)

In Chinese, there are no spaces between words. The Chinese language is based on the separation of syllables.

Use fonts that can be applied to more than one language

When choosing fonts for your texts, you need to be careful so that they look and feel the same in different languages. The font choice can significantly affect how easily the text reads. A few things should be kept in mind.

But the most crucial thing for translation is whether or not fonts are Unicode or not (such as ASCII). The Universal Coded Character Set (UCS), a complete set of characters and glyphs from many languages, is used to make Unicode fonts. These characters are encoded to ensure they look the same on all platforms and systems. ASCII, on the other hand, is only used for one language. ASCII may look nice in English, but it can't be translated well. So, you should be careful to use a font that works with Unicode. Be careful because some fonts say they are Unicode, but they only work with some code points. It could cause trouble with languages.

In different languages, the same font size may be hard to read differently. For example, 12px is easy to read in English, but the same size in Japanese could be hard to understand.

For each language, you must change the font sizes on the fly. For that, you need to keep separate style sheets for each language.

Do not hardcode text strings

You shouldn't use hardcoded strings in layouts. For a beginner, this is very tempting. But this could be a big problem when it's time to localize your Android application into a different language.

The good news is that Android Studio tells us about this. If you have already added hardcoded strings, Android Studio has an excellent way to add them to the string.xml file:

Right-click on the text and select Show Context Actions, and then Extract resource string.
Press Alt+Enter.
Click Extract resource string.
Then you'll see a dialog box.
Give that string value a preferred name.
Now, look at the string.xml file and the layout page.

Put all the strings in strings.xml

Don't hardcore any code strings when you develop your apps. Instead, put all your strings in a default strings.xml file and mark them as resources. The strings in the strings.xml file can then be quickly taken out, translated, and put back into your app (with the proper qualifiers) without having to change the code that was compiled.

Don't make more text strings and resource files than you need

You probably don't need to make a different version of every resource in your app for each locale. For example, the layout in the res/layout/main.xml file might work in any locale, so you wouldn't need to make any other layout files.

The default Android language for your app is American English. In res/values/strings.xml, all of the American English spellings for the strings used by the app are listed.

You should use British English spelling for a few crucial phrases. You want these alternative strings to be used when your app runs on a device in the United Kingdom. To do this, you could make a tiny file called res/values-en-rGB/strings.xmlwith only the strings that should be different when the app runs in the U.K. The app uses the defaults for the rest of the strings, which are set in res/values/strings.xml.

Managing String Localization with Localization Software Strings

Strings are the most important objects In a localization process. Let's look at what we need to do to make strings work in different locales.

Follow the rules for UI strings in Android

Make sure you pay close attention to how you talk to your users as you design and build your UIs. In general, use a style that is short, friendly, and to the point, and use the same style throughout your UIs.

Read the Material Design suggestions for writing style and word choice and follow them.

Also, always use the standard terms for Android, like Action Bar, Options Menu, System Bar, Notifications, and so on, whenever possible. Consistently using the correct Android terms make localization easier and the end product better for users. Additionally, you can use the glossary, which lets you create, store, and manage your project's terms in one place.

Give declared strings enough context

When you declare strings in your strings.xml file, explain how they are used. This information is beneficial to the translator and translates better. It also helps you keep track of your strings better.

Here's what we mean:

<string name="countdown">

<xliff:g id="time" example="5 days">%1$s</xliff:g> until holiday

</string>

Consider giving additional information, such as: When does it show up on the user's screen? What is the location of this text? Is it a button or a title? Should it be translated as a verb or as a noun?

To stay flexible during localization, put in some time and provide context before the translation starts. In the long run, this will pay off. For example, the previous article summarizes all the different ways to give context during localization. So that you can be sure your translators always have a great place to work.

For each language, you usually need at least one translator. Each of them might ask a dozen questions, and most of those questions are likely to be very similar. It would take you a long time to answer each one. Attaching screenshots is a very different thing.

Screenshots will help all translators understand many things at once, as each translator would see a screenshot with the current string's location marked.

A good idea would be to run the app version with Real-Time Preview set up on the Android Emulators you prefer to use. If you use Appetize.io, for example, give your team of translators the link to the app installed on the emulator so they can run it in their browsers. Or, give your translators the version they need, and they will put it on their devices.

Mark parts of the message that don't need to be translated

Often, strings have text that shouldn't be translated into other languages. Typical examples are a piece of code, a placeholder for a value, a special symbol, or a name. As you get your strings ready to be translated, look for text that shouldn't be changed and mark it, so the translator doesn't change it. Translators do not have to translate such strings because they can break the code.

Use an <xliff:g>placeholder tag to mark text that shouldn't be translated. Here's an example of a tag that makes sure the text "percent 1$s" doesn't get changed during translation, which could make the message wrong:

<string name="countdown">

<xliff:g id="time" example="5 days">%1$s</xliff:g> until holiday

</string>`

When you declare a placeholder tag, you should always add an id attribute that says what the placeholder is for. If your apps later change the value of the placeholder, make sure to add an example attribute to show how it should be used.

You can see in Crowdin the highlighted text that translators should not translate. Additionally, they will receive a notification “ do not translate.”

How to Automate the Sync of Source Content and Translations?

You may already know there's more to localization than downloading resource files, sending them to translators, and putting the translations into the codebase:

It's a waste of time to do everything by hand.
You must start downloading, sending, and integrating again if the source texts change or you get a new copy.
If you send translators a spreadsheet with strings but no context, you can expect to get a lot of questions about the lack of context, and the number of target languages will multiply those questions.

You can set up several integrations with Git tools in Crowdin. They all do a great job of keeping your systems' content in sync. For example, use integrations with GitHub, GitLab, Bitbucket, and Azure Repos. It is also possible to integrate with GitHub Actions. You can also use the Crowdin CLI or the Android Studio plugin to automatically upload source files to Crowdin and easily add translations to the codebase.

Hide duplicate strings to translate less

Sometimes, the same strings will appear in different places on your app. For example, you may have two "Next" buttons that are represented by the button next and next button translation keys. These keys, on the other hand, will have the same translation Next. It means that these keys are essentially duplicates.

If there are duplicate strings in your project, you can choose how the system should handle them:

Show – translators will translate each instance (string) separately. Duplicated strings won’t be hidden.
Show, but auto-translate them – Duplicated strings will be automatically translated but will stay visible to translators. Once the string is translated, its translation is automatically shared between the duplicates. Translators may review and re-translate those strings if necessary.
Show within a version branch (regular detection) – duplicates will be hidden only between version branches.
Show within a version branch (strict detection) – duplicates will be hidden only between version branches.
Hide (regular detection) – all duplicates will share the same translation.
Hide (strict detection) – all duplicates will share the same translation.

Regular duplicates detection: Crowdin only compares source texts when comparing strings.

Strict duplicates detection: When Crowdin compares strings, it looks at both the keys and the source texts.

Additionally, Crowdin offers a feature – Auto-substitution. It is meant to make the Translation Memory (TM) more useful by suggesting translations that are a better match. With this feature, tags, HTML entities, placeholders, numbers, and other things that can't be translated are changed to the ones used in the source strings.

Once the project owner or manager turns on the feature in the project settings, everyone who is part of the project can use it. If you are not the owner or manager of the project, ask someone who is to help you. To turn on Auto-substitution, go to Project Settings, click on the General tab, scroll down to the Translation Memory section, and check the Enable Auto-Substitution box.

Localization of a Mobile App without Resource Files

Usually, the localization of an app starts when the resource files are sent to translators, either by email (please don’t)) or automatically. The resource file comes first, and you can move on to localization.

Let's switch this up and send strings directly from your design tool (like Figma, Sketch, or Adobe XD) to be translated. Crowdin's design and development teams can work on UI localization without using resource files. It’s a new way to do localization.

Designers working on prototypes in Adobe XD, Figma, or Sketch can send strings to be translated by using keys and rules for dividing up text.

Because each localization string has its unique identifier, it's easy for development teams to add the original and translated content to the codebase.

Also, if the source files in Crowdin are in a format other than Android XML and Strings, engineers can run the custom exporters and download files in the correct format. They can use either the Crowdin API or the Crowdin download targets command in CLI versions 3.4.0.

Crowdin Bundles lets you upload a single source file (like Android XML) to your project, translate it, and then use bundles to export translations for multiple platforms by creating different file formats (Android XML for the Android app). You can add bundles and set them up so that you can export groups of strings in one of the file formats.

Crowdin's integration with design tools (Figma, Sketch, or Adobe XD) is an excellent way for designers to preview translated mockups, change them if needed, or let engineers know about the parts that should be scaled.

Find out more about the Crowdin plugins for design teams and how they make it easier to localize user interfaces.

Crowdin SDK for Android apps

You don't have to put out a new version of the app on Google Play every time you want to add a new language. Install Crowdin SDK on your app, and your Crowdin project will send you ready-to-go translations immediately. Three new features will make getting the latest translations directly from your Crowdin project's distribution, automatically upload screenshots, and see what translations look like in the app in real-time.

Over-The-Air Content Delivery
Crowdin can send new translations to your app over the air, so you don't have to update your app on Google Play. The Crowdin SDK for Android has two extra parts that you can connect: a real-time preview of the translation and an easy way to upload and tag screenshots.

Real-Time Preview
Crowdin lets translators see an instant preview of the translations they make on their app. LQA (linguistic quality assurance) should be made easier so your team can check the translated content in context.

Screenshots
Project owners and managers can take screenshots in the app version where this component is turned on. Screenshots will automatically be added to the project if the source strings are marked.

You Know How to Do Localization Now

We've gone over everything you need to think about when you start tailoring your app for your target market. There are two common myths. The first is to think everyone will use your app in English. The second would be that you can handle localization without technology.

Crowdin knows that the localization of your mobile app is a vital part of growing your market share and sales in other countries. We make it easy for you to localize your Android app, so you don't have to deal with strings and spreadsheets.

Sign up for a Crowdin or Crowdin Enterprise account to get started. Book a personal demo with our tech manager if you'd like to learn more best practices and talk about the unique ways you work.