You can upload your strings directly from you IDE using our available libraries. The reason behind this is the advanced analysis of translatable strings. Localazy will find all strings and will also recommend ignoring common private strings if they are not flagged.

Is this way of uploading useful also for apps which already have translations? #️⃣

Of course, this works for both starting and enrolled apps. Moreover, you can easily migrate all your work into Localazy and finish your current unfinished translations sooner thanks to Localazy ShareTM.

Worried about your source code? Don’t be. All your source code remains only on your machine. The only thing uploaded to Localazy are the strings to be translated.

The Localazy Android Library is an optional component that offers numerous benefits to your app, including automated upload and Over-The-Air (OTA) updates. However, we understand that you may have reservations about integrating third-party libraries into your app.

As a result, if you prefer not to use the Localazy Android Library, you can still utilize our CLI (Command-Line Interface) without any dependency on the Localazy Android library.

When you configure the Localazy Gradle plugin or change its configuration, be sure to clean the project. We use caching and incremental builds wherever possible to speed up the building of your app. Without cleaning your project, the compiled classes may not be re-compiled, and changes not applied. 

No. You can leave them unchanged. We automatically process them during the build process, update contained strings, and add missing ones.  We never touch your source files, but we always build your app with the most recent translation.

You don’t need to. Even if OTA updates are disabled, we add the most recent translation to your resources when you build your app. Our Localazy Gradle plugin does it automatically for you without touching your source files. 

You don’t need to touch your source code at all.

Localazy works fully automatically and select the best matching locale based on the user settings.

It uses the same detection mechanism as Android.

The Localazy library allows to switch locales manually if you want to use it, but it’s not required.

If you, for some reason, need to work with locales manually, see the documentation for Localazy Android library: https://localazy.com/docs/android/localazy-android-library#working-with-locales

At this moment, all you need is our Gradle plugin. When you build your app, the latest version of XML is automatically downloaded. By default, automatic publishing is enabled and changes may take up to 15 minutes to apply.

You can skip this interval by publishing the latest release manually.

Also, it’s a good idea to run Gradle clean to remove data from the cache. We use also local caching to speed up the build process.

To test your new language availability, all you need is to switch your device language as Localazy follows user device locale by default. You can, of course, offer a language selector to your users if you would like to.

The plugin indeed changes the bytecode of your app in several places. It looks for certain patterns to identify where the changes are needed. However, it never sends your source code nor the bytecode to anywhere and all changes are made strictly to inject the OTA feature.

Honestly, any plugin you add to your project can access your source code, resources and bytecode and our plugin is no different from Firebase or Google Services in term how it changes your bytecode.

We are ready to sign a contract binding us to not send your source code, resources or bytecode anywhere and inject only code strictly needed for OTA features.

The second option is to use our CLI, but you will lose the comfort of the automatic resolution of your project structure and OTA updates.

You can easily exclude strings and files from upload. Make sure you do not include your Admob IDs and so on.

All your languages are uploaded only when the uploadStrings is run for the first time.

As it’s typical to upload only the base language for subsequent uploads, we have this behavior as a default choice. You can, however, enable uploading all of them.

In your Gradle file, add:

localazy {
  // ...
  upload {
    showUploadAll true
  }
}

And then refresh your project.

The default choice uploadStrings will be changed to uploadBaseStrings and uploadAllStrings, and so you can decide whether you need to upload all (recommended only if there is a reason for it) or upload just the base language.

Suppose you have a project where the source file is a JSON file with a row in the format:

"about.moreButton": "Learn more on our website",

When using the Localazy CLI to import to Android with Format Conversions (or when you just try to export the JSON file to Android XML inside the Localazy web platform), you might notice that the format is:

<string name="about_moreButton">"Learn more on our website"</string>

Now, you might think you should delete those start and end quotation marks in the body of the XML row to achieve this result:

<string name="about_moreButton">Learn more on our website</string>

However, you can keep the quotation marks in the Android XML file because it’s a supported construct used to correctly encode white characters that would otherwise be lost in all cases. Quotation marks ensure that the exact form of your strings is preserved after conversion.

In actual use, the text will render correctly on the device.

More information can be found on the Android Developers website: String Resources

Setting up OTA updates is straightforward with our SDKs. For Android, add the Localazy Gradle plugin to your build configuration and include a few lines of initialization code in your application class. For iOS, install the Localazy Swift SDK via Swift Package Manager or CocoaPods and add initialization code to your app delegate.

After integration, configure your project in Localazy to enable OTA delivery. This involves activating the service in your project settings.

Once set up, you can control the delivery through Release Tags in the platform, deciding when translations become available to your users.

Localazy supports all major format conversions from Android XML and iOS .strings through multilingual JSON to XLIFF, qt-ts, and many more formats. You can learn more about supported file format conversions in the documentation.

In the File Management section of Localazy, when downloading your files, you can select the desired format and download your strings in any of the available file formats.

Format Conversions feature is also an integral part of the Localazy CLI tool, so if you want to automate format conversions, you will need to install Localazy CLI on your preferred platform.

Read the article: How to convert localization files into different formats?

Note: Format Conversions are available only as a part of the Professional plan

Format Conversions in Localazy allow you to convert translation files between different formats, making it easier to manage translations across multiple platforms. For instance, if you’re developing an app for iOS and Android, you can easily convert between .strings (iOS) and .xml (Android). This eliminates the need to manually maintain translations for each platform, saving time and reducing the risk of errors.

Format Conversions support placeholders across various formats, but their syntax can differ between platforms. For example, in Android, placeholders are typically in the format %1$s, while in iOS, they use %@. Localazy automatically converts these placeholders to the appropriate format for the target platform, ensuring that your translations work correctly without manual adjustments.

Some formats, like JSON or YAML, support nested structures in translation files. Localazy’s Format Conversions preserve these nested structures during conversion. When converting from a format that supports nesting to one that does not (such as from JSON to XML), Localazy flattens the structure to ensure compatibility without losing any translation data.

Plurals and arrays are managed differently across platforms, but Localazy automatically handles these conversions for you. For example, Android uses specific plural keys (one, other), while iOS handles plurals with string tables. Localazy’s Format Conversions ensure that plurals and arrays are correctly mapped and formatted to suit the target platform’s specifications.

Find out more about Format Conversions in our documentation.

A String Catalog in Xcode is a centralized file for managing localized strings in your iOS or macOS app. Instead of juggling multiple .strings files, a String Catalog stores all translations in one place, making it easier to add languages, keep translations consistent, and update your app’s user interface text.

How to create a String Catalog in Xcode:

1. Open your project in Xcode.
2. In the Project Navigator, right-click on your project folder (or the group where you want to keep the catalog).
3. Choose New File… and then under Resource, select String Catalog.
4. Name your file (e.g., Localizable.xcstrings) and click Create.

How to configure a String Catalog:

1. Select the new .xcstrings file in the Project Navigator.
2. In the editor, you’ll see a table-like view where you can add keys (string identifiers) and provide translations for each supported language.
3. To add more languages, go to your project settings, select the Info tab, click Localizations, and enable the languages you want. The new languages will appear in the catalog automatically.
4. Use the Value column for your source language, and fill in the translations for other languages in their respective columns.

When you run the app, Xcode automatically picks the correct string based on the user’s device language settings.

Using Localazy with String Catalogs: Instead of managing translations manually inside Xcode, you can connect your .xcstrings file to Localazy.

• Upload your source language to Localazy. You can do this manually in the app interface or — to speed up your workflow — use the Localazy CLI to upload files with a single command, enabling automated integration with your build or deployment process. For example:

localazy upload

This command uploads your latest .xcstrings file to Localazy automatically, so you don’t need to manually handle files every time.

Once your source is in Localazy, you can choose how to translate your project:

• Translate on your own or invite contributors and use our built-in suggestion system.
• Translate quickly in bulk, using machine translation or Localazy AI with context-aware results. This is ideal for first iterations or localization testing.
• Automate human translations with Continuous Localization. After your Localazy integration is set up, you can request translations from our professional linguists and have your projects translated automatically. The service works proactively, so you can check in only occasionally to monitor progress.

When all translations are complete, download ready-to-use .xcstrings files for all supported languages.

localazy download

This way, Localazy keeps your String Catalog in sync across all languages, reduces manual editing, and ensures faster, consistent localization.

The key benefits include:

• A centralized view of all translations.
• Easier tracking of missing or outdated strings.
• Built-in support for pluralization and variants.
• Reduced errors compared to manually editing multiple .strings files.

Xcode’s String Catalog is a replacement for traditional .strings files, designed to make localization more organized and efficient by consolidating all translations into a single, user-friendly interface.

For example, rather than maintaining separate files for source and target languages, a String Catalog groups them together. You can instantly see all language variants of a string side by side, making it faster to spot gaps or errors. This also helps developers and translators easily manage keys, track missing translations, and avoid inconsistencies.

With the Xcode String Catalog integration into Localazy, the process becomes even smoother:

• Developers push source strings to Localazy directly from the catalog.
• Professional translators, machine translation, AI, or your translator community can handle the localization.
• Completed translations sync back into the catalog automatically, keeping everything organized and up to date without extra manual steps.

This integration eliminates tedious file handling and makes scaling to multiple languages faster, more reliable, and less error-prone.

Pluralization and text variations are essential for natural-sounding translations. Different languages use different rules — for example, English typically distinguishes between singular and plural (“1 file” vs. “2 files”), while other languages, like Polish or Arabic, have three or more plural forms.

With Xcode’s String Catalog, you can define plural and variant strings directly within the catalog instead of creating multiple separate keys. For example, you might create a single entry for FileCount that includes:

• English: one = "%d file", other = "%d files"
• Polish: one = "%d plik", few = "%d pliki", many = "%d plików", other = "%d pliku"

The catalog ensures these rules are applied consistently across all supported languages.

Variations can also be defined for context, such as different messages depending on gender or device type. This keeps everything structured in one place and avoids the confusion of multiple scattered .strings entries.

With Localazy’s integration, pluralization and variations become even easier to manage:

• Localazy automatically understands the plural forms required by each language.
• Translators see the proper plural categories (e.g., “one,” “few,” “many”) with clear context, reducing mistakes.
• Localazy extracts context from XML comments and catalog metadata to give translators more guidance.
• Translations sync seamlessly back into the String Catalog, ensuring all plural forms and variations are correctly preserved.

This combination makes plural handling smooth, efficient, and reliable — especially when scaling your app to multiple languages.

When working with multiple languages in Xcode’s String Catalog, good organization and consistency are key. Here are some best practices to follow:

1. Keep a clear source language

Always start with a complete and well-structured source language. This makes it easier to track missing translations and maintain consistency.

2. Use descriptive keys

Instead of generic names like label1, use meaningful keys such as LoginButtonTitle. This helps translators and developers understand the context.

3. Take advantage of pluralization and variations

Define plural forms and variations (e.g., gender, device type) directly in the catalog to avoid hardcoding conditions in your app logic. For example:

• English: one = "%d comment", other = "%d comments"
• Czech: one = "%d komentář", few = "%d komentáře", other = "%d komentářů"

4. Add comments and context

Use the catalog’s description fields or developer comments to provide translators with context. This reduces ambiguity and improves translation quality.

5. Regularly sync and validate

Keep all language versions up to date and validate them during development. Missing or outdated translations can break the user experience.

Managing multiple languages with Localazy #️⃣

Localazy makes handling multiple languages smoother and error-free:

• Automatically extracts comments and context from String Catalogs, giving translators clear guidance.
• Provides built-in plural rules for each language, so translators know exactly what forms are required.
• Syncs translations seamlessly between Xcode and Localazy with the Localazy CLI, keeping all languages aligned.
• Supports pre-translation via machine translation, Localazy AI that understands context, and professional translators to minimize manual work.
• Tracks progress across all languages, so you instantly see which ones are complete or missing.

With these practices and Localazy’s automation, your String Catalogs stay consistent, well-structured, and ready for global audiences.

Over time, your project’s .xcstrings files may accumulate unused or outdated keys that can clutter the localization process and confuse translators. Cleaning them up keeps your String Catalog organized and efficient.

Best practices for removing unused strings:

1. Check references in your code Before deleting any string, verify that it’s no longer used in your source code. Xcode’s “Find in Project” is a quick way to search for references.

2. Use Xcode’s String Catalog editor

• Open your .xcstrings file in Xcode.
• Look for strings marked as unused (Xcode often flags these).
• Remove them directly in the catalog to keep all language variants consistent.

3. Delete carefully across all languages When you remove a key from the source language, make sure to also remove it from all other language entries in the catalog to avoid mismatches.

4. Keep version control in mind Always commit your .xcstrings changes in Git (or another Version Control System - VCS) so you can easily revert if something breaks after cleanup.

With the xcstring integration in Localazy:

• Keys deleted from your source file are detected automatically during upload.
• Removing a string in your source .xcstrings ensures it’s also cleaned up across all target languages in Localazy. If the removed string — referred to as a deprecated key in Localazy terminology — later reappears in your source file during an upload, it is restored to the active state with all associated data (context, translations, contributors, etc.).
• Translators see only the active, relevant strings, avoiding wasted effort on outdated content.

This way, your localization workflow stays clean, consistent, and free from unnecessary clutter.

OTA (Over-The-Air) updates allow you to deliver new translations to your mobile app users without requiring an app store update. Once you integrate our SDK into your Android or iOS app, it creates a connection between your app and Localazy’s delivery network. When you publish new translations on the Localazy platform, they’re automatically pushed to your CDN delivery point, from where they’re fetched by your users’ apps.

The SDK handles all the complexity of requesting, downloading, and integrating the translations into your app’s UI. It also manages caching for offline use and only downloads what’s needed to minimize bandwidth usage. This means that fixing a translation error or launching a new language can happen immediately, without waiting for app store review processes.