Giters

aurelia / i18n

A plugin that provides i18n support.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RelativeTime prevents BackendLoader from downloading resources for fallback language

josundt opened this issue · comments

commented

I'm submitting a bug report

  • Library Version:
    3.1.4

Please tell us about your environment:

  • Operating System:
    Windows 10

  • Node Version:
    14.16.1

  • NPM Version:
    6.14.12

  • Webpack
    4.44.2

  • Browser:
    all

  • Language:
    all

Current behavior:
aurelia-i18n has a RelativeTime component.
The component comes with translations for multiple languages to support relative time.

When the "i18n:locale:changed" event is triggered by the EventAggregator, relative time translations for the new language are added programatically to the configured i18next default namespace.

The idea here seems to be that by adding translations to the default namespace, the Relative Time translations would merge with the Aurelia application's own default namespace translations.

The problem with this approach is that the Relative Time translation resources are added to the default namespace before the BackendLoader had downloaded the application's translations for the default namespace.
When resources for a namespace/language has already been added to i18next by the Relative Time component, i18next never calls the BackendLoader to load the application's translations.

Summary: This bug prevents an Aurelia application's translation files for the default namespace from being downloaded by the BackendLoader.

If it is possible to add/merge the Relative Time translations after the application's translations have been loaded the problem would be solved.

Expected/desired behavior:
Default namespace translation files should be downloaded.

commented

Uh oh, that sounds logical. So I guess the backendloader merely detects the presence of the Key from the RT translations and skips applying them. I'll try to reproduce the issue and see how we can fix this.

@Sayan751 I guess this shouldnt affect the v2 since relative time is handled natively by the browser right?

commented

In our products, we have also created our own custom RelativeTime locale formatter that uses the native browser features, but falls back to the aurelia-i18n RelativeTime for browsers that lacks the native RelativeTime support.

I believe certain iOS Safari versions lack this support - even quite new versions.

Are you planning a fallback solution for v2?