Has anyone found a good option for multiplatform l...

# multiplatform

[seanf]

Has anyone found a good option for multiplatform localisation/L10n? Preferably a typesafe option.

I'm trying to migrate a GWT project which uses type-safe messages (http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Messages.html). Basically the GWT compiler generates the English .properties file from a messages interface - method names become property keys, annotation values provide the English strings - and also generates runtime classes to provide the translations (taken from the translated .properties files).

I don't need compile-time class generation - Java/ES6 Proxy objects at runtime would be fine, but I would need a way to generate the English .properties file in the common (not jvm or js) module - which means I can't just use reflection to examine .class files from a Gradle plugin. I'm starting to think I need an annotation processor - but will that work in a common module? (Update: apparently it won't.)

[bashor]

Please file an issue about it — kotl.in/issue

[bashor]

I think you can use (K)APT for JVM counterpart of your common

[seanf]

@bashor Yes, I think I can use kapt in the jvm module, but once I generate the English .properties file I want to include it as a runtime resource in the common module. I don't think that will work unless I can generate the file from the common module.

[seanf]

@bashor Which part did you mean I should file an issue about? My vague wish for multiplatform L10n, or a request for annotation processing in common modules?

[pdvrieze]

As a workaround you may be able to use kapt to generate kotlin sources. Something that may be properly supported for common modules.

[pdvrieze]

You would have to do some gradle hackery to literally copy the resource from the JVM version. It's not pretty, but is automated.

[seanf]

@pdvrieze I don't understand. Do you mean use kapt in the jvm module?

[pdvrieze]

Yes, you would use kapt in the jvm module. Generate your properties file there. Then copy that to your common module.

[pdvrieze]

Or to an appropriate location in your js module (perhaps using json works better than properties files for js).

[seanf]

Hmm. It seems like I would have to make some pretty big assumptions about the order things happen between the related modules.

[seanf]

I actually only need the file in the js module (because JS doesn't have full reflection).

[seanf]

I wonder if I can make the js module depend on the jvm module...

[pdvrieze]

If you generate to your js module (not the common one) you could easily add a task dependency on the kapt task in the jvm module to the packing task in your js module

[pdvrieze]

Just do task dependencies

[seanf]

Thanks @pdvrieze

[bashor]

Which part did you mean I should file an issue about?

@seanf I meant “supporting for l10n / i18n in general”

[seanf]

Created https://youtrack.jetbrains.com/issue/KT-21686

[bashor]

thank you