R.swift: Add Option to show development language defaults instead of keys if a translation is missing in a table.

[scaio]

The current fallback behavior for NSLocalizedString checks if a table exists for a given locale but not if the key itself exists in the table.

This means that if a key is missing (as often is the case for large products where the translations take a while to catch up) then the key itself will be returned unless a default value is specified, which currently only gets set for Base localization.

Projects using R.swift are prone to using keybased localization approaches, meaning keys are not actual English sentences but string ids (eg: screenElement.someSubElement.mainText="Some very long winded text about something etc etc etc...";).

If you use key based localization and you have missing keys this effectively blocks you from releasing an app update until you get the translations, since you don't want users to see meaningless strings which is not ideal.

Arguably, if a release cannot wait for translations, the next best thing would be to at least attempt to default the missing keys to the development language so that user impact is minimized.

[mac-cain13]

We're aiming to stay close to the behavior of Apples API. Is R.swift currently behaving different than using a plain call to NSLocalizedString would? I think NSLocalizedString would also return the key right and not the development language or am I mistaken?

[scaio]

@mac-cain13 Thanks for replying :)

NSLocalizedString will return the key unless you pass a default value in case the key is not found. This allows one you use a non natural language key based approach with NSLocalizedString such as having the key be my.buttton.text (This seems to be the recommended approach by the r.swift docs).

In an ideal world we should be able to halt releases until all translations are available. However, that is often not feasible for production apps where you may need to ship a security update urgently or where you may want to run a beta tests before all translations are available. (especially if you have a broad range of supported languages!)

On an app using NSLocalizedString I would be able to use the value field to pass a natural language value in the development language to avoid having "garbage text" be visible to the user.

This PR aims to introduce this behavior _as an opt in_ for users using non natural language keys, thus giving back some of the value functionality provided by NSLocalizedString that is currently obfuscated by R.swift.

Do you think there would be value in having this functionality in R.swift?

Is there another approach that you would recommend to support the use of non-natural language keys?

[hujunfeng]

I agree with @scaio, and I would also like to see this option to be added.

It's clear in the documentation of NSLocalizedStringWithDefaultValue that the value parameter is used to provide the fallback string. (Btw, only the Objective-C version has the complete documentation, not the Swift version.)

If we use non-natural languages keys, we would have to use NSLocalizedString like this to support fallback:

NSLocalizedString("book-tag-title", value: "Book", comment: "")

Here, "Book" would be the same as the value for the development language, but it is a hard-coded string literal. And we would have two copies of this string, one in the .string file and one at the call-site here. I don't think anyone is actually doing this because it's error-prune and hard to maintain. This is where R.swift could help by eliminating hard-coded strings and automating the process of falling back to the development language.

I couldn't find anything in Apple's Internationalization and Localization Guide that such a fallback behavior is discouraged.

In summary, I think

• It uses an official API for its intended purpose (value parameter in NSLocalizedString).
• It aligns with the benefits that R.swift has already provided.
• It can be introduced as an opt in behavior (value is also an optional parameter with default value).