How do I check if a given message has a translation available?

[jerryjappinen]

It seems that there is no way to check if a given translation message exists. I can use $i18n.exists to check if a local exists, but that's it.

I'd like to be able to perform the same checks that the plugin does when deciding what to render (for example when to fall back to the key), so I can decide to not render anything in any given situation. For example, if there is no translation for the title of the current page, I'd rather just render the app title than the untranslated key as the page title. So something like the following:

computed: {
    pageTitle: function () {
        var messageKey = 'pageTitles.' + this.$route.name;
        return 'My App' + (this.$i18n.messageExists(key) ? ' - ' + this.$t(key) : '');
    }
}

Is this possible currently?

[tikiatua]

Hi @Eiskis,

I understand your use case, but I am not sure if providing a message exists function is the best way to go about this. Especially edge cases with variable replacements and pluralization might be hard to get right as well.

Maybe another way to go about this would be to have the option to provide a default translation for a key (as second argument)

computed: {
    pageTitle: function () {
        var messageKey = 'pageTitles.' + this.$route.name;
        return 'My App' + this.$t(key, '');
    }
}

[tikiatua]

I added the function $i18n.keyExists to the plugin in version 1.3.7. Might come in handy for other use cases as well.

I will also think a little more about the option to provide a default translation key.

[jerryjappinen]

Thanks for the quick response and quick fix! I'll use keyExists for now to get around this.

I like the default translation approach a lot actually, cuts down on the boilerplate and provides a good pattern to the user that can also be documented easily. Basically I don't think rendering keys makes sense in production very often (if ever?), but now they serve as default translations which the user has no control over. This would be really useful, other localisation solutions probably have something similar.

[tikiatua]

Our initial idea was, that the key itself would be the default translation. This way you would not have to think about keys for translations strings but just use the translation string directly.

However, this proved to be not working so well if using multiple locales and changing the translations later on. Therefore the default option would probably make more sense.

[jerryjappinen]

That's exactly my experience as well. Having douple-purpose keys like that is tricky because then those keys will be in constant flux and the default translations will have to be synced across all localisation files, and thus might be duplicated who knows how man times. It's better to separate those concerns.