What an XLIFF File Is, and the One Xcode Exports

An XLIFF file is an XML file that carries your source text and, once someone translates it, the target text next to it. Tools pass it around so a translator can work on your strings without opening your app project. If you found one inside an .xcloc folder after exporting from Xcode, your job is to put a translation inside each <target> and import the folder back.

XLIFF files use the extensions .xlf and .xliff. The format exists in two incompatible generations: version 1.2, which OASIS ratified in February 2008, and the 2.x line, whose current version is 2.2 from March 2025. A 1.2 file wraps each string in <trans-unit>, while a 2.x file uses <unit> and <segment>. Apple's documentation for editing the XLIFF inside an Xcode Localization Catalog uses <trans-unit>, <source> and <target>, which are the 1.2 element names.

What the format is for

The XLIFF 1.2 specification, an OASIS Standard dated 1 February 2008, describes the XML Localization Interchange File Format as a way to store localizable data and carry it from one step of the localization process to the next, so different tools can work on the same file. Your app keeps strings in its own formats, an export step copies them into XLIFF, someone fills in translations, and an import step writes them back.

Wikipedia lists .xlf as the extension and gives the media type as application/x-xliff+xml before 2.0 and application/xliff+xml from 2.0 on. Weblate's format page lists both .xlf and .xliff, plus vendor variants such as .sdlxliff. An .xlf file and an .xliff file are the same kind of thing with a different name.

Two shapes: 1.2 and 2.x

Check which shape you have before you reach for a converter. Weblate's page says XLIFF 2.0 is a different format and isn't backwards compatible with 1.2. The XLIFF 2.2 standard, approved on 13 March 2025, comes in two parts (Core and Extended), and Wikipedia notes it is backwards compatible with 2.1 from February 2018. None of that helps a 1.2 file.

In a 1.2 document, the root holds one or more <file> elements. Each string sits in a <trans-unit> with a <source> and, after translation, a <target>. The <target> element is optional, so an untranslated export has none. Apple's own example, from its page on editing XLIFF files, looks like this once a German translation is added:

<trans-unit id="Hello, world!">
  <source>Hello, world!</source>
  <target>Hallo, Welt!</target>
  <note>A friendly greeting.</note>
</trans-unit>

A 2.x document moves the language codes to the root as srcLang and trgLang, and puts the text inside <unit> and <segment>. A trimmed sketch of the current spec's shape, with namespaces left out:

<xliff version="2.0" srcLang="en" trgLang="de">
  <unit id="greeting">
    <segment>
      <source>Hello, world!</source>
      <target>Hallo, Welt!</target>
    </segment>
  </unit>
</xliff>

<trans-unit> means the 1.2 shape; <unit> and <segment> mean 2.x. A tool page that says "supports XLIFF" without a version number could mean either one, so check before you upload.

The XLIFF file inside an .xcloc folder

When you choose Product > Export Localizations, Xcode creates an Xcode Localization Catalog: a folder with an .xcloc extension, one per language and region you picked. Xcode pulls strings from your source code, storyboards, XIBs, .strings, .stringsdict and Siri intent definition files, and adds them to an XLIFF file. For .stringsdict plurals, it adds the correct plural variants for each exported language.

Open the catalog and you'll find four things:

• contents.json, with the development region, locale, tool and version
• Localized Contents, which holds the localizable resources, including the XLIFF file
• Notes, for screenshots or other context for the translator
• Source Contents, with UI files and other resources for context

The file you edit lives in Localized Contents. You can drop your own screenshots into Notes before you send the catalog to someone.

To include all your Swift strings, enable the Use Compiler to Extract Swift Strings build setting before you export. Objective-C extraction doesn't need it. When Swift strings are missing from the XLIFF, check that setting first.

From the terminal, Apple's command is:

xcodebuild -exportLocalizations -project <projectname> -localizationPath <dirpath> -exportLanguage <targetlanguage>

The -exportLanguage part is optional.

Filling it in without a CAT tool

Agencies tend to open XLIFF in Trados, memoQ or a hosted platform. You don't need any of them for an indie app. The file is XML, and any text editor will do. Apple's steps come down to this:

1. Open the XLIFF in Localized Contents.
2. Search for <trans-unit> to find each user-facing string, including your app name.
3. Add a <target> inside that <trans-unit> with the translation.
4. Leave the id attributes, the <note> text and the <file> names alone.
5. Save, then choose Product > Import Localizations in Xcode and select the .xcloc folder.

Xcode groups strings by table. If your code used a table name, those strings sit in a separate <file> element named [table name].strings. With no table name, the file is Localizable.strings. Leave those names as Xcode wrote them.

On import, Xcode warns you about untranslated files, then updates your project's strings and .stringsdict files from the translated XLIFF. It also updates localizable resources and assets in an asset catalog. The terminal version is xcodebuild -importLocalizations -project <projectname> -localizationPath <dirpath>.

Keep the .xcloc folder intact through all of this. Import Localizations asks you to select the catalog folder, and the translated XLIFF has to be back in its Localized Contents when you do.

What an XLIFF file is not

The .xcloc folder is the package. The XLIFF is one file inside it. A .strings file or an .xcstrings string catalog is where your app keeps strings day to day; XLIFF is the interchange copy Xcode makes from them. For the iOS side of that, the guide to Xcode string catalogs covers it, and the other file formats an app ships are compared in a separate article.

Android is the other common mix-up. Android's localization guide tells you to wrap text that shouldn't be translated in an <xliff:g> tag, for example around %1$s with id="time" and example="5 days". The resources file declares xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2", which borrows the 1.2 namespace. That file is still an Android strings.xml resource. It isn't an XLIFF document, and no XLIFF tool expects it. More on the xliff:g tag inside strings.xml in the Android article.

Translating an XLIFF file with Localize Your App

To skip hand-typing every <target>, you can translate the file without a subscription: Localize Your App accepts .xliff and .xlf uploads. It's a web tool that translates app localization files with AI. Placeholders are locked, a glossary keeps product terms consistent, and translation memory reuses approved strings, with those repeats free. You review source and target side by side, edit any line, and download the same format.

Pricing is one-time credits with no subscription, and credits never expire. 1 credit translates 1 string of up to 500 characters into 1 language. You can translate into all 50 App Store Connect localizations at once or pick a subset.

The limits: it doesn't hire human translators, it has no CLI or git sync, and it doesn't store the uploaded file, only the extracted strings in your project. Exporting and importing the .xcloc catalog stays a job you do in Xcode. To keep terms consistent across languages, set up the glossary before you translate.

FAQ

What is an XLF file?

An XLF file is an XLIFF file with the .xlf extension. It's XML that holds source strings and their translations, and tools treat .xlf and .xliff the same way.

What does an XLIFF file example look like?

In the 1.2 shape Xcode's docs use, each string is a <trans-unit> holding a <source>, an optional <target> and sometimes a <note>. The 2.x shape puts <source> and <target> inside <segment>, inside <unit>.

How do I open an XLIFF file without Trados?

Open it in any text editor or code editor, since it's plain XML. For an Xcode export, add a <target> inside each <trans-unit> and import the .xcloc folder back with Product > Import Localizations.

Is a strings.xml file that contains xliff:g an XLIFF file?

No. It's an Android resource file that borrows the XLIFF 1.2 namespace for the <xliff:g> tag, which marks text the translator shouldn't change.

With an .xliff or .xlf sitting in your exports folder, you can translate your first file and review every line side by side before you download it.