Let's consider Android and its support for the Chinese language. It needs extra handling. With the Gradle plugin, we do all the heavy lifting automatically for you, but if you decide to go with Localazy CLI (e.g., if you want to use the same files for more platforms), you need to handle that manually.

Aliases 🔗

The language alias allows you to change how the language is processed. For Chinese, Localazy stores it, including the script, to be sure that your strings are translated correctly. However, you may want to output it without the script.

{
 
  "download": {
	  "langAliases": {
		  "zh-Hant-TW": "zh-TW"
	  },	  
	  // ...
  }

}

You can achieve the same result by using transformations, but it would complicate your configuration.

Expansions 🔗

The language expansion leaves the language untouched but tells the CLI to generate other variants - this is extremely useful for the mentioned Android issue with Chinese, but you can also apply it to regional locales like this:

{
 
  "download": {
	  "langExpansions": {
		  "de": ["de-DE", "de-AT", "de-CH"]
	  },	  
	  // ...
  }

}

You can achieve the same result by using several different download rules, but again, it would complicate the configuration and make it error-prone. Also, it would be complicated to generate expansions for more languages.

Format conversions 🔗

Both aliases and expansions are extremely useful for format conversions too:

{
	"conversion": {
		"actions": [
			{
				"type": "android",
				"langAlias": {
					"zh-Hant-TW": "zh-TW"
				},
				"langExpansions": {
					"zh-Hant-TW": [
						"zh-MO",
						"zh-SG"
					]
				},
				// ...
			},
			{
				"type": "ios-strings",
				"langAlias": {
					"zh-Hant-TW": "zh-TW"	
				}		
				// ...
			}
			
		]						
	}	
}

At Localazy, the locale is zh-Hant-TW but when the file is converted to Android, it's stored as zh-TW, zh-MO and zh-SG, and for iOS, it's stored as zh-TW.

💖 You might also like 🔗

Read more articles related to Android or Localazy CLI on our blog.

📚 Further reading: