TypeScript

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.