BartyCrouch icon indicating copy to clipboard operation
BartyCrouch copied to clipboard

Support for value parameter in NSLocalizedString

Open 4tune opened this issue 5 years ago • 4 comments

We use such code to automatically set default value for the strings: NSLocalizedString("account.gender.NA", value: "N/A", comment: "Title for account N/A gender")

But bartycouch creates empty strings in Localizable.strings for those strings. Is there any way to use value we set with value: as the default in Localizable.strings?

Other option would be to use lint command to remove all empty translations, but I haven't found an option for that.

4tune avatar Mar 02 '19 16:03 4tune

Thanks for reporting this issue, @4tune!

First, to clear things up, I'm not sure what you're expecting the value: "N/A" to do, should it be only added to the default language or to all languages? If to all languages, how does this improve your localization workflow, how is your example "N/A" better for your use case than an empty value (which BartyCrouch can warn against if configured via build script)?

Please also note that if you configure BartyCrouch to use the transform task as described in point 4 in the configuration section you will be able to provide one or multiple translations along the BartyCrouch.translate call.

If I understand this correctly, then what you're looking for is a command like the currently existing defaultToKeys command on the code task but for values. It could be named something liket defaultToValues but again, I'm not sure how this could improve any localization workflow, so please explain so I can understand and document this properly in the README if implemented.

Jeehut avatar Mar 04 '19 11:03 Jeehut

Regarding lint removing all empty translations:

  1. lint should not change anything in the Strings files, that's what update is there for
  2. How should that work, I'm guessing what you mean is that if a translation key has no value in any of the languages supported, then and only then should it be removed? What if someone in your project doesn't specify a value then and wonders why BartyCrouch doesn't seem to work? I'm not really sure about this ...

In any case: Since the title of this is about the value parameter in NSLocalizedString, could you please open a separate issue for this other feature request? This will allow others who also need the feature to upvote the issue.

Jeehut avatar Mar 04 '19 11:03 Jeehut

Hey @Dschee , we're actually looking for the same functionality so I can explain our particular use-case and workflow that would benefit from it.

Our current workflow, which is based on an older version of Bartycrouch, relies on mostly interface strings, so defaultsToBase comes in handy since our base is always the strings we need translated from English. Occasionally, we need to localize things in code, for which we use NSLocalizedString extensively and rely on the key to be contextual, and the value to be the "Base" string. Previously, when the Bartycrouch shell script would run and generate the entries for all the strings files, all of the languages would default to the original value, therefore fulfilling the "defaultsToValues" functionality that we are talking about. This meant that we don't ever have to touch the strings files, we can rely on putting our default, or Base values in the interfaces and in code.

The second advantage was that sometimes (rarely) we make higher priority releases without waiting for translation. This worked great before because the "defaultsToValues" functionality guaranteed that for all the languages we support, the strings themselves would be English, rather than empty. So we can release without complete translation because at least there is still text, that many of our users understand, even if it's not in their language. We would follow this up quickly with a translated release. Unfortunately, to keep this possibility, with the new version of Bartycrouch, we would need to manually specify the English value in all the strings files OR give up the contextual nature of our keys in order for us to use defaultsToKeys to get similar functionality.

Hope that clears up how it helps in our localization workflow, let me know if anything is unclear.

rebe1one avatar Oct 04 '19 20:10 rebe1one

Actually hold up, looking at the implementation, "defaultsToKeys" is actually doing the same thing as "defaultToBase" in that it defaults to the value of the localized string, so actually, we can just use that. One suggestion though, it should probably be renamed to "defaultToValue" for accuracy. @4tune

rebe1one avatar Oct 04 '19 21:10 rebe1one