Work In Progress
This documentation is in beta. It's missing lots of content, search is broken, and many links go nowhere. These problems will be fixed before release, but there's plenty of work left!
Skip to main content

Multiplatform

While we would love to be able to publish this framework for all Kotlin Multiplatform targets, we are unable to find replacements for some of the things we depend on. We also lack the time and ability to create our own ports of other libraries and tools.

If you feel up to porting something we need, please feel free to reach out!

ICU4J​

We strongly believe that we should follow the best, most modern industry standards. For that reason, we ship with support for ICU4J out of the box.

ICU4J provides two message formats — v1 and v2. These are what most developers are familiar with, but that's not all — it also provides a huge range of i18n and l10n tools, including built-in measurement formatting, number pluralisation, and all kinds of other useful things.

We feel that ICU4J (and its sister project ICU4C) provide an important set of tools that developers and translators can't afford to do without. For that reason, we can't go multiplatform without a reasonable Kotlin Multiplatform port, or at least a wrapping library that provides all ICU functions on all platforms.

Locale Objects​

We use Java's Locale objects, as this is the Locale type most developers are likely to be familiar with. We believe Kotlin should include its own Locale object in the standard library, but as of this writing, it doesn't seem like any KEEPs are open for this.

We would be open to adopting a suitable, well-maintained third-party library for this purpose.

Vanniktech​

We evaluated the Vanniktech Multiplatform Locale library to see if it matched our use-cases, and found that it hard-codes a lot of data. Specifically, there's too much hard-coded validation, which we've found:

  • Could result in the developer's political biases influencing our framework's functionality.
  • Means our framework would be unable to handle minority languages (like Esperanto) or popular Internet conlangs (like Toki Pona).

We believe that the only way we can create a framework that can support all potential languages is to use a Locale type without forced data validation — aside from validating standard formats like IETF BCP 47, of course.

Resource Bundles​

While the Java resource bundle concept is a good match for our framework, we don't have a multiplatform replacement in mind. We're not against building our own alternative against a library like moko-resources, however.