Restrict "code --default-to-keys" to development language

[iStefo]

Hi! In our app, we typically use localized strings like this:

NSLocalizedStringWithDefaultValue(@"CantRecordAudioMessage", nil, MAIN_BUNDLE,
 @"Please restart and try again.", @"Alert View Error message when audio recording failed.");

When generating strings files without the -k option, the key's value is set to "", which is good because it lets us detect missing localization. But it's also tedious because the development language's string file needs to be edited, too.

When generating strings files with the -k (and -e) option, the provided default value ("Please restart and try again.") is used as the key's value in the string file, which is great! (except that, in fact, not the key is used as default, but the default value, which is what we want anyway)

However, this is also true for all languages that are not the development language, which, again, makes it impossible to automatically detect missing translations. So, the German strings file does also get the (English) default value...

Do you know of a way to restrict the effects of the -k option to the language that is also the development language of the project? It would help us a lot and I would also be willing to implement a patch if you can point me in the right direction.

[iStefo]

Update: I managed to get the desired behavior using the modifications to CommandLineActor.swift shown below. Of course, we shouldn't assume that English is everyone's development language, right?

What do you think would make a good API for this?

[iStefo]

After looking at the new configuration format (TOML) from the work/big-refactor branch, I would propose a configuration option like this:

# No defaulting:
defaultToKeys = false

# Default to values for all languages:
defaultToKeys = true

# Default to values for certain languages:
defaultToKeys = ["en"]

This, however, still doesn't address the issue that actually the supplied value will be used, not the key, as the option suggests. Additionally, the interfaces' defaultToBase would also benefit from the same config option.

[LeveyTang]

Looking for this feature too.

[Jeehut]

@iStefo Sorry for not getting back to you earlier. Each time I saw this issue, I didn't quite understand what you needed. So to rephrase the expected feature here in my own words:

You want to have an option, like defaultToKeys = ["en"] which turns the feature on only for specific languages, not for all of them, right?

I think this makes sense and using just the existing defaultToKeys as per the configuration makes sense here. Then you would either put it to false, true` or an array of languages. I like the design, do you already have an implementation ready to review? :)

[FlineDevPublic]

@iStefo I just had a look into this again, and reviewing it now, I'm under the impression that with the Pro Localization Workflow you can simply write code like BartyCrouch.translate("some.key", translations: [.english: "Your translation"]) which BartyCrouch will turn automatically into L10n.Some.key and also it will only place the "Your translation" string you provided to the English Localizable.strings file, not in any other, they will stay empty. Doesn't this also solve your use case? :)

---

This comment was written during my regular Open Source live stream on Twitch. Follow me there to support my work!