DEV Community: Crowdin

Astro Websites Localization and Internalization

yanafeshchuk — Wed, 12 Jul 2023 09:21:21 +0000

In this article, you will learn the basics of Astro localization, so you can make your website multilingual to reach new markets. We’ll discuss i18n and localization best practices that will ensure that you can adapt an application to meet the cultural, language, and other requirements of a country or region you’re targeting.

Integrating your localization software with an Astro-based website is an important step to automating the localization process.

Let’s start with a walk-through on how to set up language sub-paths and connect Crowdin to your Astro project.

Getting Started with Astro localization

In this tutorial, we will use Crowdin to translate an English Astro website into French and Spanish.

Let’s see how we can initiate our project in Crowdin. Typically, you would follow these steps:

Sign up for a Crowdin or Crowdin Enterprise account and create a project.
Add the project name, source language, visibility and target languages. In our case, we’ll have English as the source language and French and Spanish as the target languages.
Upload the content you want to translate, such as documents, strings, or multimedia files.
Define your target languages and invite translators to join your project.
Translators can access and translate the content directly in the Crowdin Editor, using built-in translation tools such as translation memory and glossary management.
Proofreaders can review the translated content and provide feedback or approve it.
Once translations are completed, you can download the translated files and use them in your website.

Astro Site Preparation

Astro is a comprehensive web development tool for building fast websites focusing on content.
Let’s initialize a new Astro site:

# create a new project with npm
npm create astro@latest

# create a new project with pnpm
pnpm create astro@latest

# create a new project with yarn
yarn create astro

This will prompt you to enter a project name and select a template. For this tutorial, we’ll use the blog template and TypeScript as the language.

Then, organize your translations within the Astro’s publicDir, in the locales directory. In the example below, we show a simple use case of implementing language sub-paths in Astro using a JSON files to store translations. We will work with three languages, en, fr, and es. In this case, you might have the following locale structure:

public
└── locales
    ├── en
    |   └── translation.json
    └── fr
    |   └── translation.json
    └── es
        └── translation.json

The translation files will have the following structure:

public/locales/en/translation.json:

{
  "nav.home": "Home"`,
  "nav.blog": "Blog",
  "nav.about": "About"
}

public/locales/fr/translation.json:

{
  "nav.home": "Page d'Accueil",
  "nav.blog": "Blogue",
  "nav.about": "À propos de"
}

public/locales/es/translation.json:

{
  "nav.home": "Página Principal",
  "nav.blog": "Blog",
  "nav.about": "Acerca de"
}

It can be either a plain or nested JSON file depending on your needs. The filename should be the same for all languages. The only difference is the language code in the path.

Crowdin CLI Configuration

In Astro, you can incorporate Crowdin CLI in your project to:

Automate the process of updating your source files in your Crowdin project
Download translations from Crowdin and automatically save them in the correct locations
Upload all your existing translations to Crowdin in minutes The easiest way to install the Crowdin CLI is to use npm:

npm install -g @crowdin/cli

Visit the official CLI documentation to explore other installation options.

To configure Crowdin CLI in your project, run the following command:

crowdin init

You’ll be prompted to enter your Crowdin Project ID and your Personal Access Token. It will generate the crowdin.yml file in the root directory of your project.

To set up the Crowdin CLI for your Astro project, you need to add the following configuration to the crowdin.yml file:

"project_id": "project-id"
"api_token": "personal-access-token"

"base_path": "."
"preserve_hierarchy": true
"base_url": "https://api.crowdin.com" # https://{organization-name}.api.crowdin.com for Crowdin Enterprise

"files": [
  {
    "source": "/public/locales/en/translation.json", # Source language file pattern
    "translation": "/public/locales/%two_letters_code%/translation.json"  # Translation files pattern
  }
]

It’s recommended to use environment variables for referencing the token in your crowdin.yml file:

"project_id_env": "CROWDIN_PROJECT_ID"
"api_token_env": "CROWDIN_PERSONAL_TOKEN"

VCS (Git) Integrations

Crowdin provides VCS (version control systems) integrations for different platforms including GitHub, GitLab, Bitbucket, Azure Repos and other platforms.

GitHub: supports various GitHub workflows, such as pull request and push notifications, branch updates, and automatic commits.
GitLab: allows you to synchronize your source and translation files with your GitLab repository, as well as manage your project languages and track the translation progress.
Bitbucket: allow you to automate updating your source and translation files with your Bitbucket repository.
Azure Repos: allows you to synchronize your source and translation files with your Azure Repos repository

You can also use the Crowdin GitHub Action to automatically manage and synchronize localization resources with your Crowdin project using GitHub workflows.

Setting Up Language Sub-Paths in Astro

Organizing translations for your website or application to language sub-paths in Astro is easy. It simplifies the management process and guarantees a consistent user experience across your application.

Setting up these sub-paths involves including the “lang” parameter in your Astro routes, making the process straightforward. The sub-paths create distinct paths for each section of your site, each with its translations.

Let’s connect the previously created JSON files with the Astro project using the astro-i18next package.

To use the astro-i18next package, you need to install it first:

# npm
npm install astro-i18next

# yarn
yarn add astro-i18next

# pnpm
pnpm add astro-i18next

After installing the package, you can start using it to internationalize your project. To do this, you need to add astro-i18next to your astro.config.mjs:

import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

import astroI18next from  'astro-i18next';

export default defineConfig({
  site: 'https://example.com',
  integrations: [mdx(), sitemap(), astroI18next()],
});

Configure astro-i18next in your astro-i18next.config.mjs file:

/** @type {import('astro-i18next').AstroI18nextConfig} */
export default {
  defaultLocale: "en",
  locales: ["en", "fr", "es"],
};

Next, we need to use the t() function available in the astro-i18next package to translate the header link titles, for example:

---
import HeaderLink from './HeaderLink.astro';
import { SITE_TITLE } from '../consts';
import i18next, { t } from 'i18next';

const lang = i18next.language;
const base = lang === 'en' ? '' : `/${lang}`;
---

<header>
  <h2>
    {SITE_TITLE}
  </h2>
  <nav>
    <HeaderLink href={`${base}/`}>{ t('nav.home') }</HeaderLink>
    <HeaderLink href={`${base}/blog`}>{ t('nav.blog') }</HeaderLink>
    <HeaderLink href={`${base}/about`}>{ t('nav.about') }</HeaderLink>
    <HeaderLink href="https://twitter.com/astrodotbuild" target="_blank">Twitter</HeaderLink>
    <HeaderLink href="https://github.com/withastro/astro" target="_blank">GitHub</HeaderLink>
  </nav>
</header>

Note that we use the i18next.language variable to get the current language in order to build the base path for header links. The t() function is used to translate the text.

The package also provides a language switcher component that you can use to switch between languages. To use it, you need to import the LanguageSelector component from the astro-i18next package. Let’s add it to the src/components/Footer.astro component:

---
import { LanguageSelector } from 'astro-i18next/components';
---

<footer>
  <LanguageSelector showFlag={true} />
</footer>

Create localized pages using the generate command:

npx astro-i18next generate

You're all set! Now we can run the project and see the results:

npm run dev

You’re all set! Now we can run the project and see the results:
Go to the project in a web browser (http://localhost:3000) and try to change the language 🚀

The localized pages will be available at the following URLs:

http://localhost:3000 - English
http://localhost:3000/es - Spanish
http://localhost:3000/fr - French Check out a minimalistic Astro web application on GitHub.

Connecting Crowdin in an Astro Context

Connecting Crowdin to Astro is easy using APIs provided by Crowdin. To integrate Crowdin with Astro, follow these steps:

Create a project in Crowdin and set up your translation workflow.
Connect your repository to Crowdin to sync your source files and translations.

Here’s an example of using Crowdin to manage translations in an Astro website:

In Crowdin, create a new project and upload the source files you need to translate.
Set up the translation workflows, translation memory, and terminology management.
Connect your repository to Crowdin to sync your source files and translations.
To switch between languages, use the lang parameter in your Astro routes. For example, when a user visits /es/blog, the API will retrieve the Spanish translations. If the user visits /fr/blog, the API will retrieve the French translations.

i18n Implementation in Astro

Internationalization, or i18n, in Astro, refers to changing a web application to support multiple languages, date and time styles, and number styles. Visit the Astro documentation to learn more about i18n in Astro.

Considerations for Crowdin as a Translation Management System using Astro

There are aspects to consider when working with Crowdin as a TMS with the Astro web framework. These factors may need paying attention to before you can get started with your application:

Integration: Ensure that Crowdin integrates seamlessly with the Astro framework.
Translation process: Make sure that you have a simple process for handling translation requests, revisions, and approvals.
Terminology management: Use Crowdin’s terminology management feature to ensure you use consistent terminology throughout the translation process.
Translation memory: Take advantage of Crowdin’s translation memory feature to store and reuse translations for frequently used phrases and sentences.
Project management: Use Crowdin’s project management tools to keep track of the translation process, deadlines, and progress.
User management: Consider setting up user roles and permissions within Crowdin. This allows you to manage access to the translation project and ensure that the right people have access to the right information.
Performance: Test the performance of the integration between Crowdin and Astro to ensure that it performs well in production.
Error handling: Handle errors gracefully and log them meaningfully, so you can debug and resolve issues when they arise.

Wrapping Up

By utilizing Astro and Crowdin, you can streamline the localization process, and the result will be a web application accessible to a diverse global audience.
Start a free 14-day trial today to make your company multilingual with Crowdin.

Internationalization (i18n) in Next.js 13 with React Server Components

Jan Amann — Wed, 12 Apr 2023 08:32:00 +0000

With the introduction of Next.js 13 and the beta release of the App Router, React Server Components became publicly available. This new paradigm allows components that don’t require React’s interactive features such as useState and useEffect to remain server-side only.

One area that benefits from this new capability is internationalization.
Traditionally, internationalization requires a tradeoff in performance, as loading translations results in larger client-side bundles and using message parsers impacts the client runtime performance of your app.

The promise of React Server Components is that we can have our cake and eat it too. If internationalization is implemented entirely on the server side, we can achieve new levels of performance for our apps, leaving the client side for interactive features. But how can we work with this paradigm when we need interactively-controlled states that should be reflected in internationalized messages?

In this article, we’ll explore a multilingual app that displays street photography images from Unsplash. We’ll use next-intl to implement all our internationalization needs in React Server Components and we’ll look at a technique for introducing interactivity with a minimalistic client-side footprint.

Interactive demo

Fetching photos from Unsplash

A key benefit of Server Components is the ability to fetch data directly from inside components via async/await. We can use this to fetch the photos from Unsplash in our page component.

But first, we need to create our API client based on the official Unsplash SDK.

import {createApi} from 'unsplash-js';

export default createApi({
  accessKey: process.env.UNSPLASH_ACCESS_KEY
});

Once we have our Unsplash API client, we can use it in our page component.

import {OrderBy} from 'unsplash-js';
import UnsplashApiClient from './UnsplashApiClient';

export default async function Index() {
  const topicSlug = 'street-photography';

  const [topicRequest, photosRequest] = await Promise.all([
    UnsplashApiClient.topics.get({topicIdOrSlug: topicSlug}),
    UnsplashApiClient.topics.getPhotos({
      topicIdOrSlug: topicSlug,
      perPage: 4
    })
  ]);

  return (
    <PhotoViewer
      coverPhoto={topicRequest.response.cover_photo}
      photos={photosRequest.response.results}
    />
  );
}

Note: We use Promise.all to invoke both requests that we need to make in parallel. This way we avoid a request waterfall.

At this point, our app renders a simple photo grid.

The app currently uses hard-coded English labels and the dates of the photos are displayed as timestamps—not very user-friendly (yet).

Adding internationalization with `next-intl`

In addition to English, we’d like our app to be available in Spanish. Support for Server Components is currently in beta for next-intl, so we can use the installation instructions for the latest beta to set up our app for internationalization.

Formatting dates

Aside from adding a second language, we’ve already found that the app doesn’t adapt well to English users because the dates should be formatted. To achieve a good user experience, we’d like to tell the user the relative time when the photo was uploaded (e.g. “8 days ago”).

Once next-intl is set up, we can fix the formatting by using the format.relativeTime function in the component that renders each photo.

import {useFormatter} from 'next-intl';

export default function PhotoGridItem({photo}) {
  const format = useFormatter();
  const updatedAt = new Date(photo.updated_at);

  return (
    <a href={photo.links.html}>
        {/* ... */}
        <p>{format.relativeTime(updatedAt)}</p>
      </div>
    </a>
  );
}

Now the date when a photo has been updated is easier to read.

Hint: In a traditional React app that renders on both the server and client side, it can be quite a challenge to ensure that the displayed relative date is in sync across the server and client. Since these are different environments and may be in different time zones, you need to configure a mechanism to transfer the server time to the client side. By performing the formatting only on the server side, we don’t have to worry about this problem in the first place.

¡Hola! 👋 Translating our app to Spanish

Next, we can replace the static labels in the header with localized messages. These labels are passed as props from the PhotoViewer component, so this is our chance to introduce dynamic labels via the useTranslations hook.

import {useTranslations} from 'next-intl';

export default function PhotoViewer(/* ... */) {
  const t = useTranslations('PhotoViewer');

  return (
    <>
      <Header
        title={t('title')}
        description={t('description')}
      />
      {/* ... */}
    </>
  );
}

For each internationalized label we add, we need to make sure that there is an appropriate entry set up for all languages.

// en.json
{
  "PhotoViewer": {
    "title": "Street photography",
    "description": "Street photography captures real-life moments and human interactions in public places. It is a way to tell visual stories and freeze fleeting moments of time, turning the ordinary into the extraordinary."
  }
}

// es.json
{
  "PhotoViewer": {
    "title": "Street photography",
    "description": "La fotografía callejera capta momentos de la vida real y interacciones humanas en lugares públicos. Es una forma de contar historias visuales y congelar momentos fugaces del tiempo, convirtiendo lo ordinario en lo extraordinario."
  }
}

Tip: next-intl provides a TypeScript integration that helps you ensure that you’re only referencing valid message keys.

Once this is done, we can visit the Spanish version of the app at /es.

So far, so good!

Adding interactivity: Dynamic ordering of photos

By default, the Unsplash API returns the most popular photos. We want the user to be able to change the order to show the most recent photos first.

Here, the question arises whether we should resort to client-side data fetching so that we can implement this feature with useState. However, that would require us to move all of our components to the client side, resulting in an increased bundle size.

Do we have an alternative? Yes. And it’s a capability that has been around on the web for ages: search parameters (sometimes referred to as query parameters). What makes search parameters a great option for our use case is that they can be read on the server side.

So let’s modify our page component to receive searchParams via props.

export default async function Index({searchParams}) {
  const orderBy = searchParams.orderBy || OrderBy.POPULAR;

  const [/* ... */, photosRequest] = await Promise.all([
    /* ... */,
    UnsplashApiClient.topics.getPhotos({orderBy, /* ... */})
  ]);

After this change, the user can navigate to /?orderBy=latest to change the order of the displayed photos.

To make it easy for the user to change the value of the search parameter, we’d like to render an interactive select element from within a component.

We can mark the component with 'use client'; to attach an event handler and process change events from the select element. Nevertheless, we would like to keep the internationalization concerns on the server side to reduce the size of the client bundle.

Let’s have a look at the required markup for our select element.

<select>
  <option value=“popular”>Popular</option>
  <option value="latest">Latest</option>
</select>

We can split this markup into two parts:

Render the select element with an interactive Client Component.
Render the internationalized option elements with a Server Component and pass them as children to the select element.

Let’s implement the select element for the client side.

'use client';

import {useRouter} from 'next-intl/client';

export default function OrderBySelect({orderBy, children}) {
  const router = useRouter();

  function onChange(event) {
    // The `useRouter` hook from `next-intl` automatically
    // considers a potential locale prefix of the pathname.
    router.replace('/?orderBy=' + event.target.value);
  }

  return (
    <select defaultValue={orderBy} onChange={onChange}>
      {children}
    </select>
  );
}

Now, let’s use our component in PhotoViewer and provide the localized option elements as children.

import {useTranslations} from 'next-intl';
import OrderBySelect from './OrderBySelect';

export default function PhotoViewer({orderBy, /* ... */}) {
  const t = useTranslations('PhotoViewer');

  return (
    <>
      {/* ... */}
      <OrderBySelect orderBy={orderBy}>
        <option value="popular">{t('orderBy.popular')}</option>
        <option value="latest">{t('orderBy.latest')}</option>
      </OrderBySelect>
    </>
  );
}

With this pattern, the markup for the option elements is now generated on the server side and passed to the OrderBySelect, which handles the change event on the client side.

Tip: Since we have to wait for the updated markup to be generated on the server side when the order is changed, we may want to show the user a loading state. React 18 introduced the useTransition hook which is integrated with Server Components. This allows us to disable the select element while waiting for a response from the server.

import {useRouter} from 'next-intl/client';
import {useTransition} from 'react';

export default function OrderBySelect({orderBy, children}) {
  const [isTransitioning, startTransition] = useTransition();
  const router = useRouter();

  function onChange(event) {
    startTransition(() => {
      router.replace('/?orderBy=' + event.target.value);
    });
  }

  return (
    <select disabled={isTransitioning} /* ... */>
      {children}
    </select>
  );
}

Adding more interactivity: Page controls

The same pattern that we’ve explored for changing the order can be applied to page controls by introducing a page search parameter.

Note that languages have different rules for handling decimal and thousand separators. Furthermore, languages have different forms of pluralization: While English only makes a grammatical distinction between one and zero/many elements, for example Croatian has a separate form for “few” elements.

next-intl uses the ICU syntax which makes it possible to express these language subtleties.

// en.json
{
  "Pagination": {
    "info": "Page {page, number} of {totalPages, number} ({totalElements, plural, =1 {one result} other {# results}} in total)",
    // ...
  }
}

This time we don’t need to mark a component with 'use client';. Instead, we can implement this with regular anchor tags.

import {ArrowLeftIcon, ArrowRightIcon} from '@heroicons/react/24/solid';
import {Link, useTranslations} from 'next-intl';

export default function Pagination({pageInfo, orderBy}) {
  const t = useTranslations('Pagination');
  const totalPages = Math.ceil(pageInfo.totalElements / pageInfo.size);

  function getHref(page) {
    return {
      // Since we're using `Link` from next-intl, a potential locale
      // prefix of the pathname is automatically considered.
      pathname: '/',
      // Keep a potentially existing `orderBy` parameter. 
      query: {orderBy, page}
    };
  }

  return (
    <>
      {pageInfo.page > 1 && (
        <Link aria-label={t('prev')} href={getHref(pageInfo.page - 1)}>
          <ArrowLeftIcon />
        </Link>
      )}
      <p>{t('info', {...pageInfo, totalPages})}</p>
      {pageInfo.page < totalPages && (
        <Link aria-label={t('prev')} href={getHref(pageInfo.page + 1)}>
          <ArrowRightIcon />
        </Link>
      )}
    </>
  );
}

Conclusion

Server Components are a great match for internationalization

Internationalization is an important part of the user experience, whether you support multiple languages or you want to get the subtleties of a single language right. A library like next-intl can help with both cases.

Implementing internationalization in Next.js apps has historically come with a performance tradeoff, but with Server Components this is no longer the case. However, it might take some time to explore and learn patterns that will help you keep your internationalization concerns on the server side.

In our street photography viewer app, we only needed to move a single component to the client side: OrderBySelect.

Another aspect to consider is that you might want to consider implementing loading states since the network latency introduces a delay before your users see the result of their actions.

Search parameters are a great alternative to `useState`

Search parameters are a great way to implement interactive features in Next.js apps, as they help to reduce the bundle size of the client side.

Apart from performance, there are other benefits of using search parameters:

URLs with search parameters can be shared while preserving the application state.
Bookmarks preserve the state as well.
You can optionally integrate with the browser history, enabling undoing state changes via the back button.

Note however that there are also tradeoffs to consider:

Search parameter values are strings, so you may need to serialize and deserialize data types.
The URL is part of the user interface, so using many search parameters may affect readability.

You can have a look at the complete code of the example on GitHub.

Many thanks to Delba de Oliveira from Vercel for providing feedback for this article!

Cover photo by NASA on Unsplash

Webinar: From multilingual UI to multilingual company

Diana Voroniak — Thu, 09 Mar 2023 11:52:42 +0000

We’ll have a live discussion with Sarah Rosales-Hunt, who’s currently a Head of Product Content and Localization at Humu (ex. Sr. Localization Project Manager, Slack). After working both at the agency and client side, Sarah has vast experience to share. We'll be discussing what are the basic elements for a successful localization initiative, how to wok with content, and how to get ready for expanding to new markets.

In this free webinar, you’ll learn:

Where does localization start?
What kind of content should be localized first?
What are the main elements of a successful localization project?
A one-man band is also a team.
What are the types of localization teams?
What to expect from your localization software?
Automating localization regardless of where your content lives
Hosted by

Register now: http://bit.ly/3F5TMsD

About Crowdin:

Crowdin is a cloud-based localization management software. With over 2M registered users and 100K+ localization projects from all over the world. Crowdin helps companies streamline their growth by reaching people who speak different languages. Trusted by Humu, Calendly, Mojang Studios, GitLab, and other companies creating multilingual products.

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.

Node.js i18n: Agile Localization for Developers

Diana Voroniak — Fri, 25 Mar 2022 10:23:26 +0000

In today’s market, people seek personalization. They expect your app to speak their native language. In this article, we will cover how you can translate your Node.js app using a developer-friendly localization platform. Learn about the i18n framework and how to integrate your repository with a localization system to automate Node.js localization.

Make Your App Multilingual and Grow Your Revenue

Language connects people. The same principle is applied to your app development. Having localized versions of your app can grow and generate great revenue for your app by opening new markets.

The internet is somewhat similar to the real world. When you visit a place where no one speaks your mother language, you feel isolated and lost. Making your app multilingual help your customers use it more effectively and opens up opportunities to reach new audiences.

According to a recent study by Preply, most of the top apps in each tech category are also the most language-inclusive ones.

Node.js Web Application Framework

Node.js is a server-side platform built on Google Chrome's JavaScript Engine. The official documentation of Node.js states the following – ‘’Node.js is a platform built on Chrome's JavaScript runtime for easily building fast and scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.’’

If you choose Node.js as a development environment and are curious about how you can implement localization as a part of your workflow – you’re in the right place.

Node.js i18n: Localization Starting Point

If you plan to create a multilingual version of your app, you should use one of the Node.js internationalization libraries available, for example on Openbase. This article will cover the i18n-node as an example. You may choose another library according to your preferences. They do implement localization functionality pretty much in the same way.

Here are a few first steps you need to take to begin the localization of your Node.js app with i18n-node library.

The first step would be to install the package

$ npm install i18n

Then, create an i18n config object

Before we use the library, we need to configure it.

$ touch app/i18n.config.js

File: app/i18n.config.js

const { I18n } = require('i18n');
const path = require('path');

const i18n = new I18n({
  locales: ['en', 'uk'],
  defaultLocale: 'en',
  directory: path.join('./', 'locales')
});

module.exports = i18n;

We added support for 2 languages, with the default one being en (English) and the second one being uk (Ukrainian). View the whole list of all configuration options for the library to learn more.

Create an i18n object

$ touch index.js

File: index.js

const i18n = require('./app/i18n.config');

console.log(i18n.getLocales()); // ['en', 'uk']
console.log(i18n.getLocale()); // 'en'
console.log(i18n.__('Hello')); // 'Hello'
console.log(i18n.__n('You have %s message', 5)); // 'You have 5 messages'

Then in the command line, run the following:

$ node index.js

This will automatically generate a locales' directory on the root folder. It will contain the relevant translation strings for the current language:

$ tree locales locales ├── uk.json └── en.json

File: locales/en.json

{ "Hello": "Hello", "You have %s message": { "one": "You have %s message", "other": "You have %s messages" } }

Add the following line in the index.js to test the generation of translatable strings for the other language:

i18n.setLocale('uk')

File: locales/uk.json

{ "Hello": "Привіт", "You have %s message": { "one": "Ви маєте %s повідомлення", "other": "Ви маєте %s повідомлень" } }

Rerun the app to verify translations

$ node index.js Привіт Ви маєте 5 повідомлень

Automate Node.js Localization with Crowdin

Node.js localization library was created to help and save your time as a developer. However, as you can assume from a small example above, doing the actual translations into multiple languages can still be very challenging, especially for complex apps.

You will face several challenges like making sure that:

your translators do not edit the same file simultaneously or break the code
translation values are present for each language
you don’t have to spend time copy-pasting translations

You don’t have to deal with all the extra work. And why would you if there is a solution? Make localization part of your workflow and forget about those issues.

Integrate Your Repo and Localization Project

Set up an integration with your repo. Crowdin integrates with GitHub, GitLab, Bitbucket, and Azure Repos. You can also install Crowdin Console Client (CLI) which allows you to integrate with GIT, SVN, Mercurial, and more.

Crowdin will get the localization files from your repo and upload them to the Editor, where all strings from your app will look user-friendly and include the comments you provided. Once the translations are done, the system compiles them into a file and syncs them with your code as a merge request. Translations do not get to the master branch before you merge them. You can also integrate multiple branches with Crowdin at the same time, so translators can work with the texts from your feature branch before it’s rolled out, and you can release them into multiple languages at the same time.

In case you have more than one app or several products that share similar features and texts, you can share their translations and avoid translating the same content twice, saving time and money. Usually, iOS and Android app versions have much of the same content. In Crowdin, you can easily detect duplicate strings to reuse their translations.

Use Machine Translation and Translation Memory Pre-Translation

Both machine translation (MT) and translation memory (TM) will help you translate content faster and reduce translation costs. With their help, you can reduce the duration of the project even before the translators begin their work. To do this, configure pre-translation via TM or MT. You can also leverage MT to get translations of non-critical content.

On Crowdin, you can localize your product with the help of more than 40 machine engines like Microsoft Translator, Google Translate, DeepL Translator. View the list of machine engines you can use with Crowdin today.

Ensure Context for Translators

Simply put, context ensures the quality of the localized version of your app. Crowdin has created a few ways to help you provide context for translators and reduce manual work.

You can provide context using:

WYSIWYG editor view
Context for strings. Add text descriptions or labels, use Glossary terms to get relevant translations faster.
Screenshots. You can upload your game or app screenshots manually or using different integrations or add-ons, like Crowdin SDK for example. This way, translators know the location and context for each string.
In-Context Localization tool. Translators can work as if in the real app interface and preview the translations they make right there. Translations are stored within your Crowdin project, and you can decide when to pull the strings to your application.

You can learn more about the Crowdin platform by watching a short on-demand demo.

Localize Your Product with Crowdin

Automate localization by internationalizing your texts and integrating your repo with Crowdin New source strings are automatically sent to translators, and you receive translations as a merge after the work is done. Let your customers access your product in several languages. Get started and register a Crowdin account.

Crowdin Language Services: The Fastest Way to Make Your Product Multilingual

Diana Voroniak — Fri, 04 Mar 2022 08:41:32 +0000

Crowdin Language Services is the fastest way to prepare content for your multilingual audience. Along with the localization management platform, we now deliver professional translation services.

Want to reach a multilingual market? Now you have a quick and easy solution. Upload your files or connect your VCS to automate content sync and order translations from a new vendor – Crowdin Language Services.

If you need help with managing the localization process and tasks like: deciding on the target market, languages, and budget, uploading the files, ensuring translators have all the resources to provide high-quality translations, and more, Crowdin also offers to hire a virtual localization manager to handle the role of your localization lead.

Save Time on Finding the Best Translation Agency

It can be challenging to find a good translation service, especially considering the number of freelancers and agencies available on the internet today. The important things to consider when choosing your LSP can include translation expertise, delivery time, and many other factors. We wanted to give you an option where you can skip making this choice and simply select the files and order translations right away.

That’s why we added Crowdin Language Services to the list of vendors in Crowdin. You can still bring your in-house team, freelancers, or any agency of your choice. For quick translations and projects with limited time or budget, Crowdin Language Services can be the right choice. All you need to quickly translate your content is to add your files to Crowdin (manually or via an integration) and hire professionals to do translations while you focus on developing new features or creating content.

The Main Reasons to Hire Crowdin Language Services

If you hire professional translation services, you know you’re working with trained linguists. With us, you will receive high-quality translations and a fast, clear, and convenient process from start to finish. Here are a few key reasons to hire Crowdin Language Services.

Content Types and Sync with 100+ Tools

Crowdin Language Services will deal with any type of content. With us, you can localize your web or desktop software, games, apps, websites, landing pages, and more.

To avoid any manual file transfer, you can connect your Crowdin projects with repositories on GitHub, GitLab, Bitbucket, and Azure Repos.

You can also export and translate data from more than 100 applications like content management systems, file directories, marketing and customer support tools. And yes, you can do it without manual file copy-pasting. All you need is to install a respective app from the Crowdin Store and sync source files and translations between Crowdin and the tool of your choice.

Languages

Crowdin Language Services team can get started within a few days and specializes in translations into more than 100 languages, including German, English, French, Spanish, Italian, Portuguese, Dutch, Russian, Polish, Czech, Chinese, Arabic, and more.

Quality

Go with Crowdin translation services that put quality first. With us, you’ll know for sure that your content will be polished before it reaches you. We ensure continuous quality control with both automatic (QA checks, glossaries, translation memory) and professional review (proofreading).

Customer Service

The translation process is straightforward and easy to start. Crowdin Language Services complete the project within the deadline and can manage different localization projects simultaneously.

Certifications and Security

All information and content you provide to us are stored on secure servers. View our Security at Crowdin page to see our security policies, data on sub-processors, and what Crowdin does to ensure internal and application security.

Order Professional Translations From Crowdin Language Services

Start localizing your content in a matter of minutes.

To order translations, please follow these steps:

Create an account or log into Crowdin and create a localization project.
Automate your content synchronization. Connect your project with GitHub, GitLab, Bitbucket, or Azure Repos.
Go to the main page > Resources > Vendors > Crowdin Language Services > Choose a project and Create a Task.
Pick files, target languages, and buy translations.

Localize Your Product with Crowdin

Automate localization process, release your app in several languages simultaneously, and provide an enhanced experience for your global customers with Crowdin.

Get started and register a Crowdin account.

CakePHP Translation: Agile Localization for Devs

Diana Voroniak — Fri, 10 Dec 2021 15:11:53 +0000

CakePHP is an open-source web framework for PHP which uses commonly known design patterns. Based on model-view-controller, it is generally used for handling web applications, the informative CakePHP library makes the development clear.

Our article will teach you how CakePHP Translation basics can help you automate your localization and translate regular app updates with ease.

Automate Localization with VCS Integrations

Localization is an important step that opens your product to a global market. In order to reap the benefits of localization and enjoy both the result and process, it should be organized in a highly agile manner.

The best way to do it is to integrate the localization process into your development workflow. For this, use a localization management platform that integrates with your software repository.

On Crowdin, you can connect your localization projects with GitHub, GitLab, Bitbucket, Azure Repos or install Crowdin Console Client (CLI) that allows you to integrate with GIT, SVN, Mercurial, and more.

Integration with your repository ensures that the new texts from the selected branches are sent to your localization project right away, and all the translations are automatically added to your repo as a pull request.

Make all of these steps automated to save your time for other tasks.

CakePHP Localization Basics

Developers often underestimate the complexity of localization. An application aiming for a multilingual market should contain more than just translated copy. You should also consider date and time formats, currency symbols, and pluralization.

To make it easier for you to understand the basics, let’s talk about CakePHP localization and gettext.

CakePHP – Gettext

Since CakePHP follows standard gettext strategies, CakePHP localization requires storing translatable text in .po files. It is one of the most common human/machine-readable file formats.

So that's why the first step towards the multilingual CakePHP app is to install gettext.

Set Up CakePHP Translations

The simplest way to “transform” a single-language application into a multilingual application is to use the __() function in your code.

Here is an example of some code for a single-language application:

<h2>Home page</h2>

To internationalize your code, all you need to do is to wrap all strings you need to localize in __() like so:

<h2><?= __('Home page') ?></h2>

These two code examples are identical in terms of functionality – they will both send the content to the browser. The __() function will translate the passed string if a translation is available. If there are no translations, it returns the texts without any changes. That means, the original string will appear on the web page.

Note: You do not need to instantiate the L10n class. It happens automatically the first time the __() function is called.

Create Language Files

Create one or more .po files, depending on how the file is and how many languages you want. Place files under src/Locale/ and within this directory. It's important to create a subfolder for each language the application needs to support.

If you choose to use just one .po file, you'll wrap your strings with the __() helper. If you choose to have multiple .po files in order to avoid one massive file, you can use the __d() helper so that you could specify the domain (domain = name of the .po file without the .po extension).

Translation folders can be the two or three-letter ISO code of the language or the full locale name such as fr_FR, es_ES, es_DO, which contains both the language and the country where it is spoken.

View Crowdin languages codes.

/src
        /Locale
            /fr
                mywebapp.po
            /es
                mywebapp.po

The source strings will be marked with “msgid” and shouldn’t be changed. Strings marked with “msgstr” are where you put the translation. The translation starts blank and needs to be filled in. Don't forget to keep quotes around your translation.

If “msgctxt” is given, it will be used as part of the translation title, which you can use to provide the context. In the next section, we will cover more details about context.

An example translation file:

msgid "Settings and privacy"
msgstr "Paramètres et confidentialité"

Once you install the integration with your VSC system, you can customize content synchronization between your repository and Crowdin. For this, change the configuration in the Crowdin UI, or edit the configuration file based on your preferences and upload it.

For example, you can define the path for files, map your own languages to be recognizable in your localization projects, rename translation files, select files and directories that you don’t need to translate, and more.

Read more about VCS Integrations and a configuration file.

Add String Context

Providing translators with context improves translation quality, makes the translation process easier, and streamlines the QA process by reducing the possibility of user error.

You can add a “comment” to your string to give translators hints about a translatable string.

Let's look at the word "email". In English, it refers to a noun and a verb. To specify which one is used here, you can use the __x() function. The context will appear on the msgctxt line in the resulting .po file.

echo __x('noun', 'email');

echo __x('verb', 'email');

The first argument is the context of the message, and the second is the message to be translated.

msgctxt "noun"
msgid "email"
msgstr ""

Set the Default Locale

You can set the default locale in your config/app.php file by setting App.defaultLocale.

The default locale controls several aspects of your application, including the default language, the date and time formats. It can also control the number or currency format whenever any of those is displayed using CakePHP’s localization libraries.

'App' => [
    ...
    'defaultLocale' => env('APP_DEFAULT_LOCALE', 'en_US'),
    ...
]

Check out the official CakePHP documentation to discover further information about using plurals, variables, and more.

Provide Context – Improve the Translation Quality

Context ensures the quality of your localized product and makes the translation process easier. There are a lot of ways to provide context. It can be screenshots, videos, a link to the entire file, or even better – a visual preview right in the Editor where translators work.

The original context is particularly important when sentences are short or consist of few words, as often happens in our case with web applications.

To make it easier for you to provide context for translators and reduce manual work, Crowdin has created an In-Context Localization tool.

You can use the tool to create an overlay for your app. Translators can translate and receive context in real-time. In-context localization is connected with the actual project created in Crowdin, which contains the translatable files. The translators can preview their translations as if in the real app interface. Translation files are stored within your Crowdin project, and you can decide when to pull them to your application (for example, only pull them after reviewing by a proofreader, so you can be confident in the quality of the final product).

Read our article about the In-Context tool and other ways to provide context for translators on Crowdin.

Localize Your App with Crowdin

Automate localization process, release your app in several languages simultaneously, and provide an enhanced experience for your global customers with Crowdin.

Get started and register a Crowdin account.

Webinar: How to localize your mobile app and drive your app store optimization (ASO) strategy

Diana Voroniak — Thu, 09 Dec 2021 15:44:29 +0000

Did you know that including #applocalization in your app store optimization strategy could boost your app downloads?
You can learn more about this topic at our online webinar.

Join Crowdin on December 22 at 11 AM EST / 5 PM CET for a webinar on mobile localization.

Attend this free webinar to learn:

How to get started with app localization
Why context is essential when translating short copy
Publishing new translations over-the-air with no need to update the app
Driving your app store optimization strategy (ASO)
Agency VS community translations

Our Partnerships Manager Bohdan Sitarskyi and a special guest, Localization Project Manager Guillermo Umpiérrez, will discuss how you can make localization a part of your app store optimization strategy and drive more downloads.

Localize your mobile apps with Crowdin and get relevant translations, provide translators with context, and update texts faster using automation features.

Register now: https://bit.ly/3dx47zU

About Crowdin:

Crowdin is a cloud-based localization management software. With 2M registered users and 100K+ localization projects from all over the world. Efficiently create and manage all your multilingual content in one place. Localize your apps, websites, games, help documentation, designs, and all that create a native experience for your customers around the globe.

Trusted by GitHub, Avast, GitLab, Buffer, Calendly, and Wrike, and other companies creating multilingual products.

Crowdin integrates with GitHub, GitLab, Bitbucket, Azure Repos, and 100+tools. You can use our API, CLI, webhooks, apps and customize your experience depending on your needs.

Mobile Apps Localization

Diana Voroniak — Wed, 10 Nov 2021 08:16:07 +0000

Whenever you are new to localization, the best thing to keep in mind is that localization is an integral part of product development, the same as prototyping or testing. Thus, localization will require some extra setups at the beginning in order for you to create a continuous workflow later.

In case you’re afraid that localization can slow down your team and the results you make, we can change your mind. Downloading resource files, sending them to translators, and integrating translations into the codebase manually is really time-consuming, but luckily, it’s not the only option.

Learn how Crowdin helps you automate the localization of your Android or iOS mobile apps.

Quick Recap: One Project or Two for Each App?

The content of iOS and Android apps typically overlaps. In Crowdin, you can easily identify duplicate strings and ensure that the same content is not translated twice.

You can hide duplicates. Translators will see and translate only one string rather than five identical ones, while the translation will be automatically applied to duplicates. Or choose to show duplicates - if the content is precisely different and requires different translations.

You can enable Hide duplicates option in the project settings.

Unify placeholders for iOS and Android strings. This will help to treat more strings as duplicates. For example, Hello, %s! (Android) and Hello, %@! (iOS) will be matched as duplicates and will be shown to translators as Hello, [%s]! On export, you’ll get files with the placeholders in their original formatting.

Read more about how to unify placeholders in Android and iOS localization.

Send Strings Directly from Your Design Tool

Did you know that designers could send strings for translation with the keys and text segmentation rules while working on the prototypes?

Your team can send strings for translation directly from a design tool like Figma, Sketch, or Adobe XD. Don’t worry about integrating texts into the codebase. Each string has its unique identifier, so development teams can integrate both sources and translated content in the codebase without any problems.

If you set up automatic synchronization with your repo - these updates can be added automatically. In the same way, you can edit or create sources - to synchronize them back, for example, in GitHub integration - choose sync sources in the integration settings.

In addition, if the source files in Crowdin are of a different format than Android XML and Strings, engineers will be able to launch custom exporters and download the files in the appropriate format. They can use either Crowdin API or crowdin download targets command of the CLI 3.4.0 version and higher.

You can read more about custom file exporters and discover more smart ways of mobile app localization on our blog.

Crowdin's integration with their design tools allows designers to preview translated mockups, customize them as needed, or notify engineers that elements must be scaled.

Learn more about Crowdin plugins for design teams and how they help streamline user interface localization.

Update Localized Content with Over-the-Air Technology

Sometimes rolling out new versions on the App Store or Google Play each time new translations arrive is not an option. When updates happen occasionally, waiting for app verification does not cause much trouble, but if you want to deliver translations to users much faster, you should consider using Over-the-Air technology.

To use it, you need to create a distribution in your Crowdin project and install Crowdin SDK on the mobile app (Android or iOS). Distribution is a CDN vault that mirrors the translated content of your project. You can create separate distributions for different files, or one distribution per project.

Once you're done with the settings, you can create releases within the required distribution each time you'd like to update translations in your app and deliver translations to consumers immediately. You can discover even more ways to localize your mobile app on our blog.

Localize Your Product with Crowdin

Keep developing new features and improvements while translators receive new texts in real-time. Release multilingual versions for customers around the globe simultaneously. Register in Crowdin to try it out first hand, and if you’ve got any questions, contact the support team.

Development and Localization Running in Parallel: Tips for Developers

yuliyahrsh — Wed, 13 Jan 2021 14:51:03 +0000

To make your mobile or web app, website, or other product-related content multilingual you first add localization to your workflow. The next step is to automate this process, so it won’t delay your next release.

Localization should go in parallel with the development process. Meaning that each new text string created or modified by you is delivered to translators right away. Once translations are done, they are pushed to your repository as a merge/pull request automatically. This way you’ll have translations in time to deploy your next update.

How to start with automating localization?

What are the first steps? How to set up the automated workflow?

We’ve prepared a small plan for you:

1. Create a project in Crowdin

Select the source language (the one you’re translating from) and target languages (the ones you’ll be translating your content into).

2. Choose your automation approach

Manage your files using in-built integrations with tools like GitLab, GitHub, Bitbucket, or Azure Repos. You can also set up a more custom workflow using Crowdin’s CLI, API, or webhooks. All the content updates can be performed automatically on the configured schedule.

3. Translate your files in Crowdin

Invite your translators and proofreaders to the project or select a translation agency for the translation tasks.

4. Merge translations into your main branch

The system will automatically add translations to the defined folder on your side. Check the translated files and merge them into the main branch.

Supported File Formats

Crowdin supports the most common localization formats (like JSON, XML, XLIFF, INI, and so on) as well as custom file formats. Feel free to upload files into your project and start the localization. View all supported file formats in Crowdin.

Our team can create pre/post processors to customize the file import and export settings and add the support of the custom placeholders for Organization Plans. So, for example, you’ll be able to export translations in Android XML and iOS Strings formats for one source file from your Crowdin project.

Versions Management in Localization

Integrate localization into your development process. Release new features and product versions for customers speaking different languages simultaneously.

You can create branches for each version of your product in your Crowdin project. Translate only the new text in the version branch and hide the duplicates that you have already translated on the main branch.

We have a special option for duplicates – Show (recommended for versions). This option allows hiding duplicated strings only between versions – so translators will see only the difference compared to the main branch.

Integrate content from your repository on GitLab, GitHub, Bitbucket, or Azure Repos

Once you integrate your Crowdin projects with your repository, the translation team will be able to work on the localization in parallel with your development process.

Select the branches and define the path for the source files and translations – the same branches will be created in your Crowdin project immediately.
Set the synchronization for the new branches. Once you create the new branch on your repository, it will be added to your project automatically – there is no need to define each new branch manually.
The integration is already configured? Great! The system will create the service branch on your repository to send the translations there. Check the new pull/merge request before merging to the main branch.
Remove the service branch after merging to the main branch – integration will create the new service branch during the next synchronization.

Crowdin action for GitHub

Integrate localization into your workflow with the help of Crowdin Action for GitHub. View the main settings, specify which action you need to include in your GitHub workflow, and define the preferred branch for the translations.

Crowdin API

Define your localization workflow and integrate it into the development process with the selected API requests:

Add new content for translation to your Crowdin project.
Create tasks for translation or proofreading.
Check the translation status for each language or each file.
Export the translated files from your Crowdin project.
Explore the API for Crowdin and Crowdin Enterprise to select the requests beneficial for your workflow.

Read more about API for your localization project.

Console client (CLI)

Connect cross-platform Crowdin CLI directly to your repository and never deal with localization files manually again.

Use the configuration file to run the commands – it contains a description of all resources: files for localization and the locations of the corresponding translations. Sure, the first setup can take a bit more time, but all the next actions would be done just in a few clicks.

Webhooks

Webhooks will notify you about the main events from your Crowdin project, like completed translations or proofreading.

Create webhooks in the Project Settings > API tab > Webhooks or use the API tool for this, and select the actions that you would like to get the notifications about.

Localize your software and other content on Crowdin

Create your localization project on Crowdin, invite translators, and automate updates for source and translated content between Crowdin and your repo. Start receiving translations right in time for the next release.

How do you handle localization in your company? Would love to see your stories in the comments below 👇

Webinar: continuous localization means no more content copy-pasting for devs

Khrystyna Humenna — Tue, 24 Nov 2020 14:42:25 +0000

Join Crowdin this Thursday at 11 AM EST / 5 PM CET for a live webinar on continuous localization.

This free webinar is for you, if:

Your product is already multilingual, but it takes too long to copy-paste sources and translations
You keep translations in a spreadsheet
It's hard to keep up with content updates, so sometimes you end up with untranslated strings in your app
Your task is to add multilingual support to your product
Release is often delayed due to localization
You team first creates a new feature and only after sends new texts to translators
You like webinars for developers :)

Save your spot to learn how to release localized versions faster, translate several branches simultaneously, automate content updates, both for sources and translations, and more.

Register now: https://bit.ly/35YZuvf

Get 1 hour of expert training and get answers to your questions on localization. Submit your questions via the registration form or ask them during the webinar on November 26.

Can’t make the webinar? No worries. Register now for a link to the recording: https://bit.ly/35YZuvf

About Crowdin:
Crowdin is a cloud-based localization management software. With 1.7M registered users and 100K+ localization projects from all over the world. Crowdin helps companies streamline their growth by reaching people who speak different languages.

Trusted by GitHub, Avast, GitLab, Buffer, Calendly, and Wrike, and other companies creating multilingual products.

Crowdin integrates with GitHub, GitLab, Bitbucket, Azure Repos, and 40+tools. You can use our API, CLI, webhooks, apps to customize your experience to your needs.

DEV Community: Crowdin

Astro Websites Localization and Internalization

Getting Started with Astro localization

Astro Site Preparation

Crowdin CLI Configuration

VCS (Git) Integrations

Setting Up Language Sub-Paths in Astro

Connecting Crowdin in an Astro Context

i18n Implementation in Astro

Considerations for Crowdin as a Translation Management System using Astro

Wrapping Up

Internationalization (i18n) in Next.js 13 with React Server Components

Fetching photos from Unsplash

Adding internationalization with next-intl

Formatting dates

¡Hola! 👋 Translating our app to Spanish

Adding interactivity: Dynamic ordering of photos

Adding more interactivity: Page controls

Conclusion

Server Components are a great match for internationalization

Search parameters are a great alternative to useState

Webinar: From multilingual UI to multilingual company

Java i18n (Internationalization) and Localization Tutorial

Java Internationalization Is an Important Part of the Development

How to Implement Internalization in Java

ResourceBundle Class

Getting Locales List in Java

Resources

Crowdin and Resources

Let’s Go On with Our Application

Conclusion

Android App Localization: Key Steps

Reasons to Localize Your Android App

Main Steps for Android App Localization

Prioritize locales and languages you’ll begin with

Make layouts with localization in mind

Think about languages written and read from right to left

Word wrappers and line breakers

Use fonts that can be applied to more than one language

Do not hardcode text strings

Put all the strings in strings.xml

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

Managing String Localization with Localization Software Strings

Follow the rules for UI strings in Android

Give declared strings enough context

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

How to Automate the Sync of Source Content and Translations?

Hide duplicate strings to translate less

Localization of a Mobile App without Resource Files

Crowdin SDK for Android apps

You Know How to Do Localization Now

Node.js i18n: Agile Localization for Developers

Make Your App Multilingual and Grow Your Revenue

Node.js Web Application Framework

Node.js i18n: Localization Starting Point

The first step would be to install the package

Then, create an i18n config object

Create an i18n object

Rerun the app to verify translations

Automate Node.js Localization with Crowdin

Integrate Your Repo and Localization Project

Use Machine Translation and Translation Memory Pre-Translation

Ensure Context for Translators

Localize Your Product with Crowdin

Crowdin Language Services: The Fastest Way to Make Your Product Multilingual

Save Time on Finding the Best Translation Agency

The Main Reasons to Hire Crowdin Language Services

Content Types and Sync with 100+ Tools

Languages

Quality

Customer Service

Certifications and Security

Order Professional Translations From Crowdin Language Services

Localize Your Product with Crowdin

CakePHP Translation: Agile Localization for Devs

Automate Localization with VCS Integrations

CakePHP Localization Basics

CakePHP – Gettext

Set Up CakePHP Translations

Create Language Files

Adding internationalization with `next-intl`

Search parameters are a great alternative to `useState`