When choosing an Angular i18n library, consider your specific requirements rather than following a one-size-fits-all approach. For most SaaS applications like those that would use Localazy, here’s what to consider:

• If you need runtime language switching (letting users change languages without refreshing), ngx-translate is a solid choice. It’s mature, widely adopted, and offers good flexibility for dynamic content. It integrates smoothly with Localazy’s workflow and is relatively easy for developers to implement.

• For teams focused on performance and modern TypeScript integration, transloco offers advantages. It provides better typing support, more efficient rendering, and a developer-friendly API. Localazy works seamlessly with transloco’s JSON-based translation system.

• If you prefer staying within Angular’s official ecosystem and don’t need runtime language switching, Angular’s built-in i18n is worth considering. It offers excellent performance through compile-time translation and integrates naturally with Angular’s build process. Localazy’s CLI tools can automate the extraction and integration of translations with this approach.

The best choice depends on whether you prioritize runtime flexibility, developer experience, or native integration with the Angular framework. All three options work well with Localazy’s translation management system, allowing your translators to work efficiently regardless of which library your developers implement.

There are several i18n libraries available for Angular applications, each with different features and approaches to localization, here are five popular examples:

1. Angular’s Built-in i18n - The official internationalization system included with Angular. It provides powerful compile-time translation but doesn’t support runtime language switching.

2. ngx-translate - One of the most popular third-party libraries that offers runtime language switching and a simple API. It’s widely used and has extensive community support. See the official ngx-translate website for more information.

3. transloco - A newer library designed with performance in mind, offering excellent TypeScript integration and lazy loading capabilities. Check it out on the official Transloco website.

4. angular-l10n - This library is for localization of Angular apps. It allows, in addition to translation, to format dates and numbers through Internationalization API. See Angular l10n on GitHub.

5. i18next - A framework-agnostic i18n library with Angular bindings through angular-i18next. Known for its extensive features and flexibility. See i18next on GitHub.

All these libraries can be integrated with Localazy’s translation management system, allowing you to choose the technical approach that best fits your development workflow while still benefiting from our streamlined translation processes.

To download translations to their original locations, you can follow these steps. First, in the localazy.json configuration file and go to the download section. In this section, configure where you want to download your translations.

For a smoother process, ensure that you include the “path” parameter during the upload and use the same variable in the download section. Here’s an example of how to do it:

"upload": {
  "files": [
    {
      "pattern": "src/**/locale/en.ts",
      "lang": "inherited",
      "path": "${path}"
    }
  ]
},

"download": {
  "files": [
    {
      "output": "${path}/${lang}.ts"
    }
  ]
}

By setting the “path” parameter correctly, the translations will be downloaded to the respective locations specified in your localazy.json configuration file.

Your projects can often contain multiple keys with the same content. Be it button labels across a large-scale information system, including keys on the backend and frontend or Android vs. iOS versions of your app. There are two ways to approach duplicate keys with Localazy.

The first option to consider when you have two or more projects that contain duplicities is to use the Connected Projects feature, which is available with the Professional plan. Connected Projects can help you by translating identical keys across multiple projects. This feature is great for a portfolio of projects sharing duplicate keys or Android and iOS versions of the same app. When enabled, Localazy distributes existing translations between connected projects and automatically decides whether the translation can be used right away or needs to go through review first.

For a robust duplicity management that can work with duplicities inside one project and across multiple projects as well, we recommend the Duplicity Linking feature, available with the Business plan. With duplicity linking, you can define one key as the source for all other keys with the same or similar content. The other keys are then marked as hidden and get their translation from the linked key.

You can upload existing translations to your source files in Localazy File Management or follow the guide to uploading existing translations via the CLI.

In file management, you won’t see multiple versions of the same files in various languages.

You can imagine each Localazy file as a stack of its localized versions - with the source language on the bottom and all of the translated versions on top of it. So when you want to add a new language file, you update the stack.

If you want to upload translations in another language to Localazy, use the Upload existing translations option.

Yes, absolutely. You can have multiple files in different folders uploaded to the same project.

You can include files by their exact path or by using standard path wildcards ? (single character), * (anything except path separator), ** (anything including path separators).

You can control files you want to upload with exclusion rules and conditions.

Example:

"upload": {
    "type": "json",
    "files": "modules/**/en.json"
  }
 
}

The above configuration will scan for files named en.json in all subfolders of the modules folder.

The configuration process centers around the localazy.json file in your project root.

An example configuration includes:

{
    "writeKey": "your-write-key",
    "readKey": "your-read-key",
    "upload": {
        "type": "json",
        "files": {
            "pattern": "src/**/locales/*.json",
            "path": "${path}",
            "file": "${file}"
        }
    },
    "download": {
        "files": "src/locales/${lang}/${file}"
    }
}

The configuration supports variables, conditions, transformations, and format-specific features. You can also include group definitions for organizing different sets of files and rules for handling special cases.

There are two main approaches to structuring translations in a front-end project:

Centralized Approach #️⃣

All translations are stored in one location:

my-app/
└── src/
    └── assets/
        └── locale/
            ├── en.json
            └── es.json

Pros:

• Simple to set up
• Easy to find all translations in one place

Cons:

• Can become unwieldy in larger applications
• All translations load at once (potentially impacting performance)

Component-Based Approach #️⃣

Translations are distributed alongside their components:

my-app/
└── src/
    └── modules/
        ├── feature-a/
        │   └── locale/
        │       ├── en.json
        │       └── es.json
        └── feature-b/
            └── locale/
                ├── en.json
                └── es.json

Pros:

• Better organization in large applications
• Works well with lazy loading
• Teams can own their translations

Cons:

• More complex setup
• Requires additional configuration

For most applications, especially as they grow, the component-based approach offers better maintainability and scalability. However, for smaller applications, the centralized approach might be simpler to start with.

Localazy shows you the path to the original file, so you know what module you are translating.

Choose based on your project size and team structure, with the understanding that you can migrate between approaches as your needs evolve.