fkirc/attranslate

Support FormatJS ICU

592da opened this issue · 4 comments

592da commented

Describe the feature

Support FormatJS ICU Messages Format

Example https://formatjs.io/docs/react-intl/components#formattedmessage

Source (flat-json, icu, en)

{
  "active_value": "{value, select, true {active} false {inactive} other {INVALID_ACTIVE}}",
}

What Happens now (current attranslate behavior) [target lang de]

{
    "active_value": "{value, select, true {active} falsch {inaktiv} andere {unbekannt}}",
}

Desired attranslate behavior [target lang de]

{
    "active_value": "{value, select, true {active} false {inaktiv} other {unbekannt}}",
}

Basically, on FormatJS message syntax, the lib shouldn't mutate the keys that are not wrapped in inner bracelets ({})...

fkirc commented

Thanks for reporting, additional/improved matchers could be done as a PR.
But on the other hand, I am not even sure about the value of those matchers.
If you run attranslate with --matcher=none, then you might easily do any additional corrections right after the translation-process?

592da commented

Thanks for your reply @fkirc !

with matcher none i got the following result,

  "active_value": "{Wert, Auswahl, wahr {aktiv} falsch {inaktiv} andere {unbekannt}}",

which is even less relevant, I think this feature will be a huge pro for this lib over other libraries...

Thanks :)

fkirc commented

A major goal of attranslate is to make manual corrections as easy as possible (or to translate everything manually).
So if you run into matcher problems only occasionally, then I don't think that this is a huge problem.
On the other hand, if you run into matcher problems very frequently, then the only thing I can do is to merge community-PRs with improved matchers.

Adding a matcher to attranslate is pretty simple, but it should be done by someone who has a pressing need for new matchers.

fkirc commented

With regard to the matchers, I am still unsure what to do about them.
Perhaps it might make sense to expand the already existing keySearch/keyReplace features since this feature might be used as an alternative to "matchers".
I am closing this issue for now, but please feel free to re-open it if the issue is still relevant!