How to work with multiple strings files about bartycrouch

[mathebox]

Yes, thanks! That's clarifying things. I will when I can find time to work on this. I'm kind of busy right now with other stuff.

In the meantime, for everyone who needs multi-table support you can use this older version

pod 'BartyCrouch', :git => 'https://github.com/Flinesoft/BartyCrouch.git', :commit => 'a31aef6ad183b42b7b3dfc2e5e2c07bb212594ac'

and install it manually on pod install by adding this to your Podfile

post_install do |installer|
    Pod::UI.info "Installing BartyCrouch manually"
    system("make installables -C ./Pods/BartyCrouch --silent")
    system("cp -f /tmp/BartyCrouch.dst/usr/local/bin/bartycrouch ./Pods/BartyCrouch/bartycrouch")
end

[Jeehut]

You're right, supporting multiple tables is currently not in the scope of BartyCrouchs features. I'm not using them myself so I don't have plans to implement support for them in the near future. But I'd be glad to accept a merge request that attempts to add support for localization tables as long as it conforms to the contribution guidelines.

A few steps/places probably related to this feature:

• Add multiple Strings file finding support in StringsFileSearch
• Add multiple Strings file generating support in CommandLineActor

Also one question is if those differently named Strings files are all placed within one directory (potentially structured into sub directories). If not than we probably also need new command line options as currently you can only specify a directory to be searched for the resulting Strings files.

I hope this helps driving this feature forward. I'm sorry that I can't implement this feature myself (I'm currently too busy), therefore I will need the support of the community to get this done. But I'll try to be of help as good as I can.

[Jeehut]

I reverted #67 due to side effect problems. Reopening this ticket therefore.

[Jeehut]

Note that there is now a new option named --custom-localizable-strings available which you can use. It doesn't exactly solve this issue, but it may be a working alternative until this is properly implemented.

[mathebox]

This new option --custom-localizable-strings makes it a bit harder to implement this feature.
I would expect that occurrences of NSLocalizedString will search in Localizable.string if tableName = default. If the tableName is specified, I would would expect <tableName>.strings to be checked.

We now have to determine which name is overridden by --custom-localizable-strings. @Dschee What was the idea for this in your initial concept?

[Jeehut]

We currently have a project which is splitted into multiple sub-projects (not my idea) and each sub-project has it's own .strings-File and those are not allowed to be called the same due to restrictions with our translation service LingoHub. While we could have used a tableName, not all of our toolset is compatible with that and that's why I introduced a possibility to enforce a file name.

But I don't see any problems with the tableName = default cause the logic behind the --custom-localizable-strings is that it enforces a specific file name to replace the default Localizable.strings file. That means, when the option is set, then the default should become the specified String instead Localizable. But if a different tableName is given, you can still use that and ignore what's specified in --custom-localizable-strings.

Does that answer your question or concerns?