DB Localization add-on

Add-ons
#1

Hi @mario
Your add-on DB Localization is interesting. I have couple of questions:

  1. Performance: you mentioned slow for first-time loading. If there are many users, can the cache load by user A be used when user B or C logs in or it has to be the same user?

  2. If I have multiple instances of the same application installed in a different server, what will be suggested methodology to copy the Locale from one server/database to others?

#2

Hi,

here are the answers:

  1. the slowness is there independent of the user. So what happens is that on the web-layer of the CUBA app it keeps a cache for the whole tomcat instance of all keys that are requested. So if user A klicks through all paths of the app, user B and C should have a fast app right from the get go. You can also just try it out on your own. Just log in as User A, open some screens, logout and back in as User B and go to the same screens

  2. Are you talking about a clustered environment? In this case the cache is kept on each web-layer tomcat additionally.

Cheers
Mario

#3

Thank you Mario.
for question # 2, not clustered but suppose i have 2 customers where my application is deployed on-premise servers of respective customers. In case I have maintained all the locale translations, is there any robust way copying that to the 2nd customer’s database?

#4

I’m not sure I really understand your use-case.

In case you as the developer want to define the translations and know them beforehand and want to package it up to a bundle for easy distribution to the customer then the best way to do that is to put it into source files message.properties.

The addons message resolution functionality works (as described here: GitHub - mariodavid/cuba-component-db-localization: CUBA component that allows to manage application translation at runtime in the database) that it will first look into the DB and if it does not find a translation it will look up the value in the message.properties files.

But I think you might be speaking about that you provide a “visible default” via the config UI with all the translations already in and then they can adjust it?

In this case, the addon does not provide that capability right now by directly loading the translations from the message.properties file. Instead what you have to do it to perform the initial translation import (see GitHub - mariodavid/cuba-component-db-localization: CUBA component that allows to manage application translation at runtime in the database). After that you have a lot of DB entries for the ddcdl_Localization entity.

These values you can transfer to other installations via the regular mechanisms that always apply for CUBA related DB config transfers (like Entity Inspector > Export as JSON e.g.).

I hope this helps.

Cheers
Mario

#5

Yes, that’s what i meant. Thanks for your comments/update.
regards