A question about server-side translations for v14. I'm under the impression that the js/ts-language files that we register in the backoffice would only register these translations for the client-side backoffice app. Makes sense. In the past I've performed some translations on the server side, e.g. for error/validation messages, etc. Is this something that should be avoided in Bellissima and onwards? I've noticed that the

ILocalizedTextService

is still in the C# and not marked as obsolete so would be interesting to know if anyone has some more insights.

I have asked the same a few weekes ago, nop answer I ended up rendering client side now

I've also gone 100% client side which kind of works in most cases, sometimes I want to generate "logs" for operations like s StringBuilder with Generated: * 5 new Articles * 6 new Blog Posts and so on, kind of painful to model as translation keys for the front end and the fact that the

ILocalizedTextService

is still around made me wonder. If not used I guess I would be good to remove it from the codebase before the V14 release.

I reckon perhaps an oversight thats its not obselted in V14, but I could be wrong @Jacob Overgaard do you know or know anyone who would know?

You can use the ILocalizedTextService freely on the backend. In fact, we use it to render serverside-only stuff such as email templates. For serverclient translations, we are working towards an "error code" approach, meaning that we'll send strings resembling enums to the client such as UserNotFound and then the client will look up that code in its own translation files.

@Jacob Overgaard thanks man, just so that I understand things right. 1. Translations from client-side files (the localization extensions) will not be available using

ILocalizedTextService

right? 2. Does

ILocalizedTextService

work as in older versions? Meaning a "Lang"-folder in the package with xml files? Cheers!

Correct on both accounts!

Great! Btw. I like the approach of using error codes so will try to go down that path

Would't it be nice that it can pick up the registered translations so we don't have two files to maintain (in case you still need a translation in the backoffice)..

Then we would also need an endpoint to fetch translations from the server, which is hardly a concern for the management api