Nesting/interpolation of translation keys

[LudvigHz]

We are trying to move to tolgee as a translation management, and currently use i18n. The integration works fine, but using the i18n native format in the tolgee platform isn't really the best, so we want to switch to ICU (or whatever is supported best by the platform).

One feature we use quite a bit currently is translation key nesting¹ which allow you to nest translation keys in other keys. This is very useful since we change some words based on the users context, but not entire sentences and most translations.

F.ex.

{
  "simple_value": "bread"

  // Another user might have
  "simple_value": "baguette"
}

And they have other common translations, like:

{
    "buy_bread": "Do you want to purchase this $t(bread)?"
}

The value enclosed in $t() would get translated and the nested value would be interpolated. This saves us a ton of translation keys that are identical except for just a few words. Is there some way of doing the same with tolgee? Or could there be a plan to implement the feauture?

If this is something that could be accepted in tolgee, I'd be happy to create a PR.
Or if this is something that can be achieved with a plugin, I'd love to know if it's possible.

Footnotes

1. https://www.i18next.com/translation-function/nesting ↩

[stepan662]

Hey, we don't support this feature, however you can use Tolgee with i18next if this is a crucial for you. https://tolgee.io/js-sdk/integrations/i18next/installation

[LudvigHz]

I do understand, in that to use the i18next integration, you'll need to use ICU format (which is very minor change) for the platform to understand properly. And otherwise it should work the same.

And we could use it this way, with the params mentioned. However the major drawback is that the tolgee cli parser does not extract the keys when using i18next, meaning we don't get the sync feature, which is what we ultimately want to ensure all translation keys exist and remove developer friction. I took a look at using a custom extractor for the cli, but it didn't seem trivial to use any of i18next's tools to do this. So without the nested keys (since we need to use ICU), there are no reason not to just use tolgee directly, rendering the i18next integration useless for our usecase (which is not a negative).

[LudvigHz]

I also tested using translated keys as parameters to the i18next t() function. And sadly it does not seem to work, so that is not a solution.

[stepan662]

Ok, ok.

What do you mean by

you'll need to use ICU format (which is very minor change) for the platform to understand properly

We do have ICU support in the editor, do you have some case where it doesn't work properly?

[LudvigHz]

Sorry. I've been investigating the options while this discussion has taken place. I will try to sum up the current state of this problem and usage with i18next as I see it. I will mention that we have moved to tolgee completely now and we are very satisfied. But I do think that there are some things that we should continue to improve on and that could be improved in tolgee as well to make migrating from other frameworks easier.

So, currently this is our setup:

• We use i18next with i18next-react to translate in our app. This is configured with the tolgee i18next plugin. This works quite well.
• In our i18next configuration we have options to use { and } as prefix and suffix for interpolation so we don't get syntax errors in tolgee. We can not use ICU (with i18next-icu) at the moment since we require nesting translations. (I reckon this can be solved with a custom tolgee plugin to translate nested strings)

This base is quite nice, but a problem we see is that the pricing of the cloud offering is more than ideal (especially since we just added another language, adding 33% to our cost). To avoid adding unnecessary strings, we want to continue to use the nesting. This saves on the amount of translations to maintain and also reduces cost. We also want to use tolgee sync to be able to remove unused strings (which we also can't due to extensive use of dynamic keys) which is why we want to move away from i18next. We also want to use ICU as this could remove alot of our duplicate strings with only plural differences.

So I think the solution to this issue as it stands is for us to try to create a custom plugin for nested keys so that we can move away from i18next and gradually typesafe and sync all keys so that we can reduce the cost using the sync.

To sum up, we want to use ICU natively but we are blocked by requiring nested keys. And we want to use tolgee/react for better TS support and sync but we can't due to our requirement of nested keys.

[stepan662]

Ok, let me know if you'd find any issue while creating the custom plugin.