Is there a way to not fail on invalid translations, but fallback in non-breakable maner

[sidoruk-sv]

For keys, where some invalid key or non-passed variable is used, all the application is broken with an unhandled exception.

For example:

1. key with minus for unescape, that is valid for i18next without ICU, but will fail your production when using with ICU plugin:

Example key:

{
  "test_unascaped_variable__key": "some {- key}"
}

Runtime exception:

  SyntaxError: Expected "," or "}" but "k" found.

      at peg$buildException (../../../../../src/parser.js:363:14)
      at Function.peg$parse (../../../../../src/parser.js:1382:13)
      at new MessageFormat (../../../../../src/core.js:21:27)
      at ICU.parse (node_modules/i18next-icu/dist/commonjs/index.js:120:14)
      at Translator.extendTranslation (node_modules/i18next/dist/cjs/i18next.js:708:31)
      at Translator.translate (node_modules/i18next/dist/cjs/i18next.js:692:20)
      at I18n.t (node_modules/i18next/dist/cjs/i18next.js:2139:80)
      at fixedT (node_modules/i18next/dist/cjs/i18next.js:2122:23)
      at TestComponentInvalidKey (src/TranslateProvider/TranslateProvider.driver.tsx:65:48)

2. non-passed variable also works great (is ignoring) with i18next

{
	"test_empty_variable": "some absent here {variable}"
}

but also causing the runtime exception

The intl string context variable 'variable' was not provided to the string 'some absent here {variable}'

      at MessageFormat.format (../../../../../src/core.js:48:17)
      at ICU.parse (node_modules/i18next-icu/dist/commonjs/index.js:124:17)
      at Translator.extendTranslation (node_modules/i18next/dist/cjs/i18next.js:708:31)
      at Translator.translate (node_modules/i18next/dist/cjs/i18next.js:692:20)
      at I18n.t (node_modules/i18next/dist/cjs/i18next.js:2139:80)
      at fixedT (node_modules/i18next/dist/cjs/i18next.js:2122:23)
      at TestComponentInvalidKey (src/TranslateProvider/TranslateProvider.driver.tsx:66:51)

It is OK to fix those errors one time to not getting exceptions on production when it is a small project.

But when the translation process is separated from development, it could be harmful that localization could break the whole application.

So as a fallback showing translated key, without interpolated invalid value (so showing in UI some absent here {variable}) is better, then failing with an exception. And showing React error boundaries errors for every place where translations are affected (could be in any key, any language).

Otherwise, we had to add some tests for checking translation files somehow (need to be invented), before using them.

[jamuhl]

Feel free to provide a PR

[mihanizm56]

The same problem - the whole app fails if one parameter was not provided to the translation =(

[jamuhl]

@mihanizm56 why not providing a PR doing a try/catch somewhere around here: https://github.com/i18next/i18next-icu/blob/master/src/index.js#L79

[mihanizm56]

@mihanizm56 why not providing a PR doing a try/catch somewhere around here: https://github.com/i18next/i18next-icu/blob/master/src/index.js#L79

Not so useful to wrap lib methods into try/catch