search

FlineDev / BartyCrouch

Localization/I18n: Incrementally update/translate your Strings files from .swift, .h, .m(m), .storyboard or .xib files.
MIT License
1.37k stars 121 forks source link

BartyCrouch + SwiftGen: "additive = false" option does not work #233

Closed lukemmtt closed 2 years ago

lukemmtt commented 3 years ago

Update

It appears that this issue may not be strictly a BartyCrouch bug, but rather a bug in how BartyCrouch works alongside SwiftGen.

After I experienced this additive bug, I tried using this library: https://github.com/ijoshsmith/abandoned-strings , which claims to do what this "additive = false" function is supposed to do. That library also failed to work as expected, so I did some digging.

I found that the abandoned-strings script functions by scanning your project's .strings files, and searches for the localized keys in your project's .swift files. SwiftGen of course generates a .swift file strings.swift with Enums corresponding to each of the keys in your .strings files, and so the "abandoned-strings" script always returns a message indicated "all source keys are in use, no abandoned strings found", since it's finding all of the .strings keys in the .swift file. Similarly, if you delete the Strings.swift file, the abandoned-strings script says "All of your strings are abandoned".

Thus, I realize that if I want to continue using BartyCrouch + SwiftGen, I need another approach to identifying unused keys. I need to scan my project not for the .strings keys themselves, but rather the resultant Enums that SwiftGen is creating.

Ultimately, I was able to achieve my goal (and more) by using Periphery which identifies unused code (including Enums). And I see that @Jeehut also contributes to that project, so thank you for that!

Original post

Expected Behavior

The readme says of the code option additive:

additive: Prevents cleaning up keys not found in code.

Bartycrouch has been working well in my project for months, but I noticed there are keys in my Localizable.strings file that are no longer used in my project. I want to remove them, and I observed that the additive option seems to describe the behavior I'm looking for—effectively removing abandoned strings from my Localizable.strings file.

So I set this additive value to false, expecting that the Bartycrouch build script would iterate through the source keys in my Localizable.strings file and remove any keys that were not found in my Xcode project.

Actual Behavior

Changed additive value to false, saved .toml file, ran Xcode build, build script executes. No change to .strings file.

Steps to Reproduce the Problem

  1. Create Xcode project with Localizable.strings file
  2. Add keys to Localizable.strings file without including them in any part of the Xcode project
  3. Set additive to false
  4. Build Xcode project
  5. See that the unused keys remain in the Localizable.strings file.

Specifications

Jeehut commented 3 years ago

@lukemmtt BartyCrouch actually (currently) doesn't detect the usage of keys in code itself. Instead, it uses the ExtractLocStrings tool developed by Apple and shipped alongside Xcode. This tool basically is able to detect Strings keys from code and generate a Strings file from it. That's what BartyCrouch does under the hood. And setting additive to false simply means that only keys generated by ExtractLocStrings will be kept. But that tool doesn't check if the String key is ever being called from anywhere within the project. Instead it just collects all Strings keys it can find.

Please note that we are not making any claims about checking the usage of keys when additive is set to false, thus you're just expecting something from BartyCrouch that it never supported. The additive option is just documented as what it does when it's set to true:

Prevents cleaning up keys not found in code.

So this is a new feature request, not a bug. I'm changing the tag. Also, I don't see any easy way to add this feature, so it might never be added. Unless you have an idea how it could be done. My feeling is, that an entirely different localization approach would be needed to get this working.

FlineDevPublic commented 2 years ago

Revisiting this again in my stream I think the solution @lukemmtt has found via SwiftGen and Periphery is exactly how I would also recommend this to be solved and I doubt that even after investing a lot of time into such a feature, that it would work better than with the SwiftGen/Periphery approach. So I would consider this feature request "out of scope" of this tool. Closing.