connecting to existing localization system?

[dbaroncelli]

Is this library connecting to the existing Android and iOS localization systems?
or is it providing a new standard for multi-platform localization?

The use case in my apps would be to define the localization strings just once inside KMP commonMain, rather than being able to access Android and iOS localization systems.

[Alex009]

@dbaroncelli hi. moko-resources use existing android and ios localization systems.
for android plugin generated resources in res as android plugin required.
for apple targets (now ios and macos) plugin generates Localizable.strings, Localizable.strings.plist and other apple resources formats.

you can define localization just in commonMain/resources and use it

[dbaroncelli]

oh wow, really interesting, I didn't know that you could define localization strings in commonMain, which would work in both Android and iOS
so is KMP able to recognize the device language settings in iOS too?
what about for Kotlin/JS?

[Alex009]

We should not recognize language manually - it's os resources system responsibility.
Js for now not implemented and not in plans. We support Android, iOS and macos now. Also @nrobi144 in progress of jvm support implementation. We open to external contribution and I can support with implementation of new targets

[nrobi144]

Also @dbaroncelli we have an example with localization in common here.
And moko has samples for all the resources (colors, strings, etc..)

[dbaroncelli]

@Alex009 @nrobi144
I am still confused, I think I didn't understand properly.
I am just interested in defining commonMain string resources and being able to access them from the CommonMain code only. I don't need to access string resources from the Android-specific code or from the iOS-specific code.
What it's not clear to me, is whether defining string resources in CommonMain is something provided by Kotlin MultiPlatform framework itself, or it's something specific of the Moko resources library.

[Alex009]

moko-resources works on base of platform resources engine. on android and ios (and jvm too) it significally different.
we can't get android string resource as String in common part because resources in android Context dependend

[dbaroncelli]

Ok, so I think I now understand that CommonMain on its own doesn’t provide string localization. This is happening only because of the MokoResources library.

What it’s yet not clear is the difference between the localization happening just in common, which @nrobi144 was showing, and the mechanism of exporting the common strings into the Android and iOS localization system.
Does the "localization in common" also exports the string into the Android and iOS localization system? And in such case, is this happening via the MokoResources plugin?

In case of the "localization in common", what happens when the language is changed in the device, and you return back to the app? Is the new language applied directly to strings in the app?

[nrobi144]

@dbaroncelli on Android, the resources will be actually merged, but that's how it works with every dependency that has resources on Android -> You can access the resources with R.

But the plugin actually generates for every platform the Moko specific resources too. So it should behave like you'd write the native translation conforming to the platform specific mechanisms

And yes, it should behave exactly like it would on native, language change included