You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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
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.
Hello. In our project we use moko-resources only to generate native
xml
andstrings
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 fromLocalizable.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:
resulting the line in
Localizable.strings
:Before 0.24.0 it was properly converted to:
Is there any workaround to keep the original behaviour for iOS?
The text was updated successfully, but these errors were encountered: