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).

[kuls14]

Any updates on this issue? I'm facing the same problem, my app has more than 10 languages support and most of the time translation is lagging behind development so it would be nice to have fallback to the default language.

[juanj]

I also think it will be really great if this can be implemented, as it is not uncommon for translation to lag behind development.

@mac-cain13 As I understand, this has not been implemented because the idea is to keep R.swift close to how the Apple own API works as much as possible. I argue that if that is the case, this should be implemented because, as hujunfeng pointed out, the parameter value is part of the official implementation and it is a valid use case to use it as a fallback value, and by not having a way of accessing it R.swift may be drifting from the NSLocalizedString behavior.

[tomlokhorst]

As of version 7.0.0, Rswift now falls back to development language, if no language was specified.