icerockdev / moko-resources

Resources access for mobile (android & ios) Kotlin Multiplatform development
https://moko.icerock.dev/
Apache License 2.0
1.11k stars 121 forks source link

[iOS] 0.24+ breaks swifgen structured strings template #748

Open OSemenovBoyarka opened 3 months ago

OSemenovBoyarka commented 3 months ago

Hello. In our project we use moko-resources only to generate native xml and strings files from KMM module for Android and iOS respectively. Then we use generated files natively in Android/iOS modules.

For iOS we also use SwiftGen tool to generate Swift enums with strings from Localizable.strings.

We use structured template, that help us to build easy to navigate swift enums, where strings are organized in subenums grouped by specific screen or usecase in the app: https://github.com/SwiftGen/SwiftGen/blob/stable/Documentation/templates/strings/structured-swift5.md

Starting from the 0.24.0, moko-resources replaces all . symbols in resource keys with _ (before it was done only for Android). That change makes it impossible to use structured SwiftGen template: E.g:

<string name="Button.Title.try_again">Try Again</string>

resulting the line in Localizable.strings:

"Button_Title_try_again" = "Try Again";

Before 0.24.0 it was properly converted to:

"Button.Title.try_again" = "Try Again";

Is there any workaround to keep the original behaviour for iOS?

OSemenovBoyarka commented 3 months ago

It looks like the breaking change introduced in this commit - https://github.com/icerockdev/moko-resources/commit/128b86c0d95d79b92a675d38fd82b28295c15e49

Alex009 commented 3 months ago

hi! we don't think about this use case. i think we can add some option in configuration that will enable different logic.

in 0.24 we do same keys for all platforms because functions that search resource by resource name require same value for all platforms. but you use case interesting and i think we should support it too

OSemenovBoyarka commented 3 months ago

Thanks for the reply! Yep, having the config option will definitely do the trick. It looks like we need a way to have different keys for platform files and internal resources, used by KMM part.