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

[Feat] Autogenerate `.strings` files #258

Closed noah-nuebling closed 2 years ago

noah-nuebling commented 2 years ago

Problem Statement

If a translator wants to add a new language, and does that through Xcode, all the translated UI strings in the .strings files will be automatically copied over from the Base localisation.

It might be nicer to start with a blank slate, where none of the UI strings for the new language are filled in automatically.

I've found no way to turn this off in Xcode. So I wish bartycrouch could do this.

Also Xcode doesn't autogenerate the Localizable.strings file for me. It can only autogenerate the .strings files for IB files.

Suggested Solution

Add a new command to bartycrouch bartycrouch add <language> that automatically generates the .strings files for the new language and fills them out according to your settings.

Jeehut commented 2 years ago

@noah-nuebling That sounds like a useful feature if you have many Strings files in your project. But it involves integrating with the Xcode project file which adds to the complexity. I won't have time to implement this feature (I shifted my focus onto ReMafoX instead – feel free to request this feature there), but I'd review a PR adding this as long as it doesn't complicate things too much and keeps the Xcode project integration lean.

Note that for projects with just one or few Strings files, you can simply remove all contents of the Strings files manually and just run BartyCrouchs normalization, which will add all keys with no translation value in them thanks to the "harmonize with source" option.

noah-nuebling commented 2 years ago

That's a pretty nice workaround I can live with that I think.

I have a little bit of experience trying to extract info from Xcode project files and I definitely understand your weariness of that.

Thanks!

Jeehut commented 2 years ago

Closing this as "Out of Scope" as there's a workaround available.