aymanizz / ktor-i18n Goto Github PK

Is your feature request related to a problem? Please describe.
The i18n extension doesn't support multi-modules. All the string resources must live inside the main app module.

Describe the solution you'd like
I don't have any ideas at the moment.

Describe alternatives you've considered
I use a simple Gradle script to merge all the string resources from different modules.

Is your feature request related to a problem? Please describe.
I've been looking for an optimized way to use i18n with FreeMarker, see bellow how and what I've used currently.

Describe the solution you'd like
I don't know if it's possible; I would love to be able to call call.t from FreeMarker, as a function, or with a custom tag.

Describe alternatives you've considered
Currently I'm passing translations as a map, but it's not optimized at all, as I need to have explicit declarations of the ones I need:

call.respond(FreeMarkerContent("test.ftl", mapOf(
    "t" to mapOf(
        "key" to call.t(R("key")),
        // ...
    ),
    // Other custom data ...
)))

Additional context
I saw there is a function feature in FreeMarker, but I'm unable to pass call.t as a function, it gave me an error (it's passed as a string with the hash of the object and I cannot call it).

Currently, the route-dependent localizations are supported using a prefix. An improvement to this might be to use route interceptors to resolve localization for specific parts of the routes tree.

This doesn't necessarily replace the prefix-based method unless using a route interceptor can do all the features provided by the prefix-based method with minimal effort.

As it looks like a few things (package names, etc.) have changed

Add ability to specify a localization depending on the current route, for example the localization for the routes under /en route would be English. This could be supported through route parameters /{localization} or a specialized route builder.

Describe the bug
When supporting multiple locales based on the same language, the logic to find the best locale given a header is not adequate.

To Reproduce
Given: a server supportedLocales = en-US, en-AU, en-IE, en-GB, and others
When: a request with en-GB header is received
Then: en-US will be used.

Expected behavior
Expected: en-GB to be used

Additional context

I would need to do more tests, but it seems it's a simple case of switching in I18n.kt
from:

        val locale = Locale.filter(ranges, i18n.supportedLocales).firstOrNull()
            ?: Locale.lookup(ranges, i18n.supportedLocales)
            ?: i18n.defaultLocale

to:

        val locale = Locale.lookup(ranges, i18n.supportedLocales)
            ?: Locale.filter(ranges, i18n.supportedLocales).firstOrNull()
            ?: i18n.defaultLocale

it happens because Locale.filter(...).firstOrNull() will match the first locale and ignore that a more specific locale exists in the range, while the Java implementation for lookup() was created to find the best match.

Is your feature request related to a problem? Please describe.

• I need support for CLDR plural rules (https://www.unicode.org/cldr/cldr-aux/charts/27/supplemental/language_plural_rules.html) that's the format when exporting from phrase.com
• I need support to use different resource bundle depending on a request header.

Describe the solution you'd like
I would do the code and open a PR trying the best I can to not break any existing API but supporting the extra features.

• extra parameter on the class R to define the type of plural stye to use (the current number based option/default) and CLDR based (the new option)
• introduce a private val CallResolverKey = AttributeKey<ResourceBundleMessageResolver?>("CallResourceBundleMessageResolver") so that on the call to fun ApplicationCall.t( it would delegate the to a different resolver (with a different baseName)

Describe alternatives you've considered
¯\_(ツ)_/¯ I don't know forking the project maybe.

Describe the bug
I am using Ktor-i18n version 2.0.0 and I realized that there is an encoding issue when encoding German characters like ä or ü.
Those characters become >> �

To Reproduce
Please create a resource with German characters for example Messages_de.properties:
unavailable = Nicht verfügbar

Expected behavior
Characters should be encoded correctly.