NSLocationTemporaryUsageDescriptionDictionary translations gets removed about bartycrouch

[patricks]

@Jeehut Ok now I got you. My final solution is that I added the en local version of the InfoPlist.strings file.

[Jeehut]

@patricks Thank you for bringing this up. You are right that we are no longer ignoring strings files names InfoPlist.strings (there was never a reason to do that, it was introduced accidentally due to a misunderstanding) since version 4.9.0. This might be the reason you see this happen just now. But generally there can only be 2 reasons for keys being removed:

1. The BartyCrouch Strings file parsers Regex doesn't recognize the key in the Strings file when reading it, so it disappears when writing during an update. A common reason for this in InfoPlist.strings files seems to be that some people don't have their keys surrounded by quotes, see also my comment here.
2. You have configured BartyCrouch to run the normalize task at the top of your config file (on by default) and you have the harmonizeWithSource option set to true in your config files normalize section. Then BartyCrouch will make sure that all languages have the same keys as your source language, so it will add all missing keys and remove all that are not available in the source language. To turn this behavior off, you can just set harmonizeWithSource to false in your config file, like this:

[update.normalize]
paths = ["."]
subpathsToIgnore = [".git", "carthage", "pods", "build", ".build", "docs"]
sourceLocale = "en"
harmonizeWithSource = false
sortByKeys = true

Does this help? If not, please provide an example InfoPlist.strings file with that key so I can better understand. Maybe this key needs special handling in some way? But if it's just a normal key like any other, see my two points above.

[patricks]

@Jeehut I think this key needs some handling, because there basic keys are listed in the Info.plist itself.

Since iOS 14 there is this temporary location usage feature available. To inform the user why the app requires a location now you can set special info texts per use case. These keys are defined in the Info.plist as dictionary.

For details see:
NSLocationTemporaryUsageDescriptionDictionary

These keys have to be translated in the InfoPlist.strings files.

"friends" = "Eine Position wird benötigt um Freunde zu finden";
"coffee" = "Eine Position wird benötigt um Kaffeehäuser in der Umgebung zu finden";

Tuning off harmonizeWithSource wouldn't be a really good workaround for use, because we use this feature to cleanup our translation files.

[Jeehut]

@patricks Thank you for the additional info. But from the documentation it's still not clear to me how the Stings file might look like. Could you please provide an example (you can redact the exact translations if needed), so I can reproduce and fix? Thank you!

[patricks]

@Jeehut the InfosPlists.strings file looks exactly as the code provided above:

"friends" = "Eine Position wird benötigt um Freunde zu finden";

And here is the InfoPlist file (cut):

 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSLocationTemporaryUsageDescriptionDictionary</key>
	<dict>
		<key>friends</key>
		<string>A position is required to find your friends</string>
	</dict>
</dict>
</plist>

[Jeehut]

@patricks I see, so that was already the entries in the InfoPlist.strings file, I thought there was some kind of dictionary structure in the strings file that we have to support, such as:

"NSLocationTemporaryUsageDescriptionDictionary" = {
    "friends" = "Eine Position wird benötigt um Freunde zu finden";
    "coffee" = "Eine Position wird benötigt um Kaffeehäuser in der Umgebung zu finden";
}

😅

But it looks like the entries in your Strings file are plain old "normal" keys, so no new structure needed. When I put the Strings content you shared into a Regex checker, it perfectly matches the Regex used in BartyCrouch:

So, case 1 I mentioned in my comment above shouldn't be the reason why it gets deleted. This leaves us with case 2. If I understand your use case correctly, what you want is:

1. Use the normalize task including the harmonizeWithSource option set to true and sourceLocale set to en for most of your Strings files.
2. For the Info.plist file only, you don't have a locale en and thus the keys get deleted in your other translations, too. What you want is a way to set a different sourceLocale for just the InfoPlist.strings files OR to turn off harmonizeWithSource only for the InfoPlit.strings file.

Thankfully, this should be possible already. What you need to do is:

1. Keep your default settings in your root level .bartycrouch.toml file, but add "InfoPlist.strings" to your subPathToIgnore so they don't get updated when you run the bartycrouch update comment on the root path.
2. Add a new .bartycrouch.toml file to the subpath you are ignoring in the root file now, but here, change the configuration (both the paths need to be updated and also the sourceLocale changed to a language you actually have a Strings file for OR the harmonizeWithSource option set to false).
3. (If you use the build-script) Update the build-script to not only run bartycrouch update -x and bartycrouch lint -x, but add a third call to bartycrouch update -x -p /your/subpath and a fourth to bartycrouch lint -x -p /your/subpath. (You might need to extract the InfoPlist.strings file into its own parent folder in case it shared the same with others, e.g. to SupportingFiles.)

Please note also that a much simpler solution would be if you just added the en locale version to your InfoPlist.strings file, then you don't need to create a second configuration file at all.

Please tell me if this works or provide more context (e.g. your full .bartycrouch.toml contents) so I can better understand the problem.