that an empty message is shown. In my case getI18nString returns undefined but the resource keys definitely exist in i18n/strings_en.json. I used the same resource keys on my configuration page for testing purpose and there everything works as expected.
I had a look into the source code of the spotify and qobuz plugin but both don’t use localized strings when showing toast messages. The webradio plugin calls getI18nStringthe same way and there it works.
The documentation only explains how localization works for the configuration pages but not for things like toast messages.
Shouldn’t this code load the localization resources into a dictionary when volumio starts and then getI18nString should return the correct localized string?
Please tell me what I am doing wrong here. I really wish to localize my whole plugin and not just the configuration page.
That seem to be inconsistent. I would suggest to provide localization for toast messages too. Why should somebody want to localize the UI configuration pages but not the toast messages?
Think about the following use case:
The user has entered some invalid configuration parameters and trys to save them. Everything shown to the the user is translated to German but the error toast message that appears because of the invalid configuration parameters is in English.
I can concur, only text that stays ‘within’ the plugin is translatable with your own strings.json.
Because a toastmessage is sent from the core, the context is no longer the plugin, but Volumio core, hence you cannot use the ‘normal’ translation method (which uses the calling context). You could work around this by implementing your own translation method in the plugin.
This applies to (at least):
Agreed it’s easier to just be able to pass along the context as an overload maybe
I think it would be not a problem to add full localization support to Volumio. The changes in the app/index.js would be quiet small I think.
Shall I try to implement it and create a PR or is it definitely not wished to be supported?