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
The addons message resolution functionality works (as described here: https://github.com/mariodavid/cuba-component-db-localization#message-resolution) that it will first look into the DB and if it does not find a translation it will look up the value in the
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 https://github.com/mariodavid/cuba-component-db-localization#initial-localization-import). After that you have a lot of DB entries for the
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.