This feature is available in the Business plan

Export aliases allow you to export content through non-api means (CDN, CLI, web interface) with different key names and to different files than what they have been originally uploaded from.

This feature allows for new localization workflows and faciliates many existing ones. See use cases section to learn more.

Export aliases management #️⃣

Manage aliases for a single key #️⃣

To define an export alias for a source key, navigate to Source language page and from the three dots option select Manage export aliases

To create an export path alias, click on Add new export path and create a new export path alias or select an existing one if available. You can define a name and path as well as change the file format different from the original file’s format.

Manage export path aliases for multiple source keys #️⃣

You can add alternative export path alias in batch. Select multiple keys and choose Add new export path from the batch options menu.

Terminology #️⃣

Export alias #️⃣

Export aliases consist of key aliases and export file aliases.

Key alias #️⃣

This is an alternative key name for the source key. A key alias can be defined in the scope of the original file as well as within the alternative export file. There is no limitation to the number of key aliases per source key.

Export file alias #️⃣

An alternative file with a different file name, file path and optionally also a different format. Both original source keys as well as key aliases can be generated in export file aliases (depending on your project settings). There is no limitation to the number of export file aliases in project or how many keys the export alias is linked to.

What content is generated #️⃣

The rule of thumb is that key aliases in export file aliases are always generated. The tricky part is what original content is going to be generated and thus exportable.

The generated content depends on your project configuration which you can find in Settings -> General Settings -> Import & Export -> Content generation. The are various options which control whether original files and original key names are also generated or not.

Generate source keys and key aliases in original files and export file aliases #️⃣

This is the default behavior. Source keys will be generated in source files and export file aliases. Key aliases will also be generated in source files and export file aliases.

Generate key aliases in export file aliases #️⃣

With this option none of the originally uploaded content will be generated. Neither source keys nor original files can be exported via non-api means. Only key aliases in export path aliases will be generated. When there is no key aliases in an export path alias defined for a source key, the source key won’t be generated at all.

Generate key aliases if defined, else source keys in original files and export file aliases #️⃣

All source keys are generated in some form in both original and export file aliases. If there source key doesn’t have any key alias, the source key is generated in the original file and in the export file aliases. If there is at least one key alias, it’s generated instead of the source key.

Generate key aliases if defined, else source keys in export file aliases if defined, else in original files #️⃣

Relatedly to the previous option, this applies the conditional generation to source keys as well to original files. In other words, either a source key or key aliases will be generated in export path aliases when there is at least one defined, otherwise in the original file. All source keys will be generated in some form.

Use cases #️⃣

Export aliases can help you anytime you wish to export your content in a form that differs from the form it was uploaded. That is especially useful in the following instances.

Share strings between iOS and Android projects #️⃣

Localazy provides various tools how efficiently share translations between iOS and Android. For example, you may choose one of the projects to be the Source of Truth and use Format conversions to convert the translation keys into the format required in the other one. However, this is not viable if not only the format, but also the key naming should be different.

That’s where export aliases come into play. Instead of using the format conversions, you could define key aliases and export file aliases with the desired format for all the keys in Localazy.

Let’s say you’d select Android project as the Source of Truth. Therefore, source keys would be uploaded from this project and only translations would be downloaded back.

First, make sure you generation settings is set to Generate key aliases if defined, else source keys in original files and export file aliases

Then in the Android project, create localazy.json file in the root of the project with the following configuration and adjust to match your structure.

{
    "writeKey": "<your-write-key>",
    "readKey": "<your-read-key>",
    
    "upload": {
      "type": "android",
      "files": [
          {
              "pattern": "app/src/main/res/values/strings.xml",
              "lang": "inherited",
              "path": "${path}"
          }
      ]       
    },
    
    "download": {
        "files": {
            "output": "app/src/main/res/values-${langAndroidRes}/strings.xml",
            "conditions": "containsWord: xml, ${types}"
        },
        "includeSourceLang": false
    }
    
  }

The crucial part is the conditions statement in the download section which makes sure that only xml files targeted for Android will be downloaded. Since this project serves as the source of truth, we don’t download the source language content ("includeSourceLang": false).

To make use of the content uploaded from Android and of the export aliases you have defined, use the following configuration in localazy.json in the root the iOS project.

{
    "readKey": "<your-read-key>",
    
    "download": {
        "files": {
            "output": "${iosLprojFolder}/Localizable.strings",
            "conditions": "containsWord: ios, ${types}"
        },
        "includeSourceLang": true
    }
    
  }

This is much simpler, because the whole upload section is omitted. That’s because the Android project serves as the source of truth and thus no content should be uploaded from the iOS project. Similarly to the previous configuration, the conditions statement is crucial to download only keys targeted for iOS.

Use Figma as the Source of Truth #️⃣

If you don’t want to manually rename each text node in Figma and choose the target Localazy files for upload, you can upload all the content from Figma into a single Localazy file and use ID as source key names.

You can organize the content via export aliases in Localazy and make use of the content uploaded from Figma elsewhere, in your coding project for example. The recommended generation option is Generate key aliases in export file aliases as it is likely that you don’t want to export the original keys accumulated in a single file in Localazy, but only the keys for which you’ve defined export aliases.

This approach goes very well hand-in-hand with our key clustering feature which aggregates multiple keys with the same value uploaded via the Figma plugin under a single Localazy key which makes the export aliases management easier.

You can advantegously use this approach in combiation with sharing strings between iOS and Android projects. Instead of choosing one of the projects as the source of truth, in both you make us of the content uploaded from Figma.

Quite likely you’ll want to make use of the source keys in code using CLI. To do that, create localazy.json file in the root of your project and adjust the following configuration to your needs. The following configuration only specifies the download block since Figma serves as the source of truth. The content will be exported to file paths which you defined as export path aliases and in a JSON file named after the language’s code.

{
    "readKey": "<your-read-key>",
    
    "download": {
        "files": "${path}/${lang}.json",
        "includeSourceLang": true
    }
    
  }

Move key to another file for export #️⃣

When you move a key to another file outside of Localazy the system looses track that it treated as an existing key that moved rather as a new key. Instead, you should define an export path alias for the selected key(s) so that Localazy can keep on tracking the source key’s data.

The recommended generation settings depend on whether you wish to generate the key in the original file as well or not. If you do, then you can keep the default settings Generate source keys and key aliases in original files and export file aliases. If you don’t then you should select Generate key aliases if defined, else source keys in export file aliases if defined, else in original files.