How to use base localization with xcstrings

App Store Distribution & Marketing General
laviallb360 OP
Created
Replies 3
Boosts 0
Views 647
Participants 3

Before migrating to xcstrings for i18n, our project used Xcode's base localization. We want to preserve that pattern after the migration, but haven't found a clean way to do it.

First attempt — a "base" identifier in both the project configuration and the xcstrings files. This fails: the compiler inconsistently emits either a base.lproj or a Base.lproj folder, and the casing mismatch breaks the App Store Connect upload.

Fallback — a "und" entry, "Undetermined" under ISO 639-2, which Apple documents as a valid language identifier. This behaves correctly at every visible step:

  • the build generates a und.lproj folder, as expected;
  • the ASC upload succeeds with no warning;
  • "Undetermined" appears in the ASC list of available languages;
  • the build is downloadable on TestFlight and distributable on the App Store, with no warning.

But there's one silent failure: once a "und" build is shipped, the app/version becomes invisible — on the App Store, on iOS, and on the website.

We currently work around this by stripping every "und" entry from the project before shipping. But we genuinely need the base-localization pattern, and this manual removal isn't something we're comfortable relying on.

Is there a supported way to keep a neutral/base localization in xcstrings that both passes ASC upload and stays visible on the store?

Answered by DTS Engineer in 907778022

As my colleague mentioned, there is no way to define a "a language that is usable for developers and won't be visible to users" when using a String catalog. The Default Localization, which you can see and change by selecting your project > Info > Localizations in in Xcode, is similar to the concept of Base in many ways, but it's a real localization visible to users, if the language matches.

und is a valid ISO code and is supported by the build tool chain, but is not supported by the App Store index generation process, becauseund can't be mapped to any country or region, and hence can't be tied to any country-specific index database.

So the behavior you have seen is pretty much as-designed. Feel free to file a feedback report to voice your opinion though, if you see that the behavior impacts your workflow negatively.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Replies  3
Boosts 0
Views  647
Participants  3
Systems Engineer OP
Apple

Base localization is a concept only used for Storyboards where there is a shared UI for all languages, then strings within are extracted and localized for each language. Base is not a language.

For general localization with strings, instead Xcode relies on a Development Language that you can set in your Xcode project settings (select your project in the File Navigator on the left, then your project in the left column, then the Localization section under the Info tab). By default this is set to English, and other languages will be automatically updated from this development/“base” language.
laviallb360 OP

Base is not a language, but it provides translation. Base localization, when set as the development language, also helps differentiate "development" from production. It defines a language that is usable for developers and won't be visible to users.

This lets the developers work with actual translations that provide context and are immutable, while the translators can update and change the wording depending on "a better use of the language", marketing, or business correction.

With xcstrings, we haven't found a way to differentiate "developers' English" from "production English". This is a requirement for our development and translation teams.

I don't think there is any way to have Xcode build the Base.lproj folder; this is why we picked "und," as it represents an undefined language.

DTS Engineer OP
Apple
Recommended

As my colleague mentioned, there is no way to define a "a language that is usable for developers and won't be visible to users" when using a String catalog. The Default Localization, which you can see and change by selecting your project > Info > Localizations in in Xcode, is similar to the concept of Base in many ways, but it's a real localization visible to users, if the language matches.

und is a valid ISO code and is supported by the build tool chain, but is not supported by the App Store index generation process, becauseund can't be mapped to any country or region, and hence can't be tied to any country-specific index database.

So the behavior you have seen is pretty much as-designed. Feel free to file a feedback report to voice your opinion though, if you see that the behavior impacts your workflow negatively.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.