Verify multiple languages

[danielsaidi]

Hi,

Hope you're all doing well.

I love using SwiftGen, since it brings "type safety" to your localized strings. If you accidentally rename or remove a required key, your app won't build.

However, if your app is localized for multiple languages, you can only be sure that the keys you use in your app exist in the Localizable.strings file you are using when generating the enum file, right?. If they are not present in any of the other localizable files, your app will still compile.

Is there any way to account for this? I guess you could add a fastlane build step that iterates through all languages and generates the swift file for each language, tries to build the app and aborts if any key is missing in the file.

Would that be your recommended course of action, or is there some built-in feature that I missed?

All the best!

[AliSoftware]

Hello @danielsaidi

If they are not present in any of the other localizable files, your app will still compile.

Yes, it will compile… and it will be a totally correct and valid configuration. I actually have some of my apps configured that way, not translating everything in all localisations except the Base one. That's how i18n works.

The way localisation works in iOS is that if a given key is missing in one specific language, the runtime always fallback to the default language.

• This default language is what you specified as the Base language (Base.lproj) if you use Base localization (this is the recommended setting)
• If you don't use Base.lproj, the language specified in the "Development Region" setting of your project is used, defaulting to "en.lproj"
• (If you don't have a .lproj directory for your Development Region, I believe your app might be rejected during submission anyway, as this wouldn't make sense)

So even if a given key isn't present in, say, fr.lproj but you ask for it in your code, it will resolve to a default value. (The app will not crash, thankfully!). And that's the expected behaviour and how i18n is supposed to work in iOS. This way, you can have all your strings in Base.lproj and only some translations but not everything in fr.lproj. Or you can have everything translated in en.lproj but only some specific variants translated for en-us.lproj for American english, etc.

---

So typically the way you use SwiftGen would be to index only your Base.lproj/Localizable.strings which is supposed to contain a value for all the possible keys you'll use in your code. Some of those keys might be absent in other .lproj localisations but that's ok, as long as all your keys are at least listed in Base.lproj. That's why this is the file you'll typically run swiftgen against.

[danielsaidi]

Thanks for the fast reply :)

Yeah, localization works as you describe. Missing language keys translate to a default value.

For instance, say that I have an app that is localized in Swedish and English, then use the Swedish Localizable.strings file to generate the SwiftGen enum. All keys in the Swedish file will end up in the enum. If I then use a L10n key that does not exist in the English file, I will get a default value, which is the key name itself.

However, if I would now use the English file to generate the enum, my app would now fail to build, since the key is not present in the English translation file. Clearly, you use the same file at all times, but if you would change, that is what would happen.

Now, I would argue that a missing language key in any translation file should be considered to be a bug in the app, since it would make the app display incorrectly in the languages that miss this key.

SwiftGen works perfectly as it is, but I would love a (an optional?) verification feature, that iterates through all language files and verifies that all files contains the same keys.

Does this make sense?

I could add this as a separate build step in Fastlane, running SwiftGen for each existing language and trying to build the app after generating the enum for that language. However, I think that this will take a long time, since it would result in a O(n) total build time, since the app must be rebuilt for each language.

[djbe]

I consider this something that isn't part of SwiftGen. It's up to the developer to ensure what behaviour he/she wants.

You could use a script to compare the keys present in all strings files, and produce a warning for missing (or extra) keys.

[AliSoftware]

If I then use a L10n key that does not exist in the English file, I will get a default value, which is the key name itself.

Only if English is set up as your default (Development Region). Which would be the wrong thing to do in your example.

You should always set the Development Region to the main language the application is developed in, which will always have values defined for all localized keys.

In your example, if the app is first developed in Swedish and Swedish is your main language for this application, then Swedish should be your Development Region. Or you should rename sv.lproj to Base.lproj and make it your Base localization language, whatever you prefer, but the important thing is to tell your project that Swedish is the reference language that will provide default for strings not translated in other languages. And then you'll use the sv.lproj/Localizable.strings with SwiftGen.

[AliSoftware]

Now, I would argue that a missing language key in any translation file should be considered to be a bug in the app, since it would make the app display incorrectly in the languages that miss this key.

That's not how it works. If a key is missing in a given language, the default value isn't the key itself. It's the value of that key in the default language (Development Region or Base.lproj). And only if you misconfigured your Development Region or the key doesn't exist either in the Base language / Development Region, then it defaults to the key name to show you that you misconfigured something.

I agree with @djbe, checking that you configured your Development Region or Base.lproj correctly isn't the job of SwiftGen imho. So many scenario could be considered totally valid even for some keys missing, like it's still totally valid to have keys missing in en-gb.lproj as long as they are present in en.lproj, even if English isn't the Development Region (because, yes, because defaulting to the Development Region or Base.lproj, it defaults to the language-without-variant if you were in a specific variant, so it defaults to xx.lproj if it can't find a key in xx-vv.lproj which are variants of a locale for specific region, like American english vs. UK english, etc).

So a lot of those configurations can totally be entirely valid, and produce valid translations (and not the key names) even if keys are missing in some region-specific variants of a locale or even a given locale.

[danielsaidi]

You are absolutely 100% correct. I focused too narrowly on my individual case, where a fallback language is a no go and did not consider the cases where you want local variations on top of a baseline.

I will solve my specific case with a shell script.

Thank you!

[AliSoftware]

Example:

// Base.lproj (or fr.lproj and Development Region set to "fr")
"key 1" = "Ceci est une belle couleur";
"key 2" = "Celle-là aussi";
"key 3" = "OK";

// en.lproj
"key 1" = "This is a fine color";
"key 2" = "This is another one";

// en-gb.lproj
"key 1" = "This is a fine colour";

It's totally valid for en.lproj to miss "key 3", and to en-gb.lproj to miss both "key 2" and "key 3".

• If the user has its iPhone in Swedish, "key 1" will translate to "Ceci est une belle couleur" because there's no sv.lproj
• If the user has its iPhone in UK English, "key 2" will translate to "This is another one", because there's no value for en-gb.lproj so it would default to the value in en.lproj
• If the user has its iPhone in UK English, "key 3" will translate to "OK", because there's no value for "key 3" in en-gb.lproj but falling back to en.lproj doesn't give any value either, so the fallback will continue down to Base.lproj where all the defaults are supposed to be present.

[AliSoftware]

As for your shell script, I'd remind you that a Localizable.strings is nothing more than a PLIST (but written in its text format instead of XML format), so maybe using some tools like plutil or /usr/libexec/PlistBuddy to manipulate the file would make it easier to extract the list of keys of each strings file (and sort them alphabetically and then make a diff on all of them to compare)?