Hi everyone. Me and @Jamie Craane have created a gradle plugin to help with cross platform localization. Simply said, you create one file with all strings in all languages and the plugin will generate Kotlin native code so you can use those strings in a shared project (for example a view model). It also creates actual implementations for iOS, Android and JS. We’ve just open sourced it and are in early stages but are looking for feedback and contributions. Have a look at https://github.com/jcraane/kmm-resources/

At first glance seems similar to moko-resources, though moko doesn’t have (hopefully yet) a js target. Are there any significant usage and/or implementation differences?

Yes, although I’ve never used moko myself since we started building this around the same time moko started. But at least one small difference is that with our plugin, you can completely resolve a resource to a String within Kotlin code. moko will only get you a StringDesc and then you need to resolve it in platform specific code. And we use YAML for the localizations file which we quite liked. Some more small difference. But yes, the goal we try to achieve is pretty much the same as what moko tries to achieve.

hi! good to see altertaive solutions for moko-resources and other opinions 🙂 how you resolve string from common code on android? :)

in commonMain we generate an expected function like this:

expect fun L.General.withParams(value0: String, value1: String): String

this is represented in the following way in the yaml file:

general:
  withParams:
    nl: "Een %1$s tekst met een %2$s"
    en: "A piece of %1$s with a piece of %2$s"

in androidMain we generate an actual implementation which delegates to Android string resources:

actual fun L.General.withParams(value0: String, value1: String): String = localizationContext?.getString(R.string.l_general_withParams, value0, value1) ?: ""

The string resource files are also generated from the same input file:

<string name="l.general.withParams">A piece of %1$s with a piece of %2$s</string>

Hope this answers your question.

where you setup

localizationContext

?

You need to initialize that in the onCreate of your application. We may provide an Android Initializer in the future which can be registered in the Manifest which then can initialize this context.

so you use ApplicationContext instead of acitivtyContext?

Yes. In our app we wrap it in a ContextWrapper so a configuration with a correct locale is set. The context wrapper part is not documented yet in the plugin, this is something which is good to add.