DB localizations - preview

Hi,

I’ve created a new application component which allows to manage message localizations in the running application.

If you have any thoughts on that, like bug, feature requests etc. I would love to hear from you.

I’ll just copy over the README.md so you get an impression on what it does:

CUBA component - DB Localization

This application component let’s you manage your localization in the DB instead of properties files in the application.
This way you can at runtime of the application create and change translations. Since it is possible to do in application
screens, translations can be easily managed by people outside of development.

Installation

  1. db-localization is available in the CUBA marketplace
  2. Select a version of the add-on which is compatible with the platform version used in your project:
Platform Version Add-on Version
7.0.x 0.1.x

The latest version is: Download

Add custom application component to your project:

  • Artifact group: de.diedavids.cuba.dblocalization
  • Artifact name: dblocalization-global
  • Version: add-on version
dependencies {
  appComponent("de.diedavids.cuba.dblocalization:dblocalization-global:*addon-version*")
}

Using the application component

Once the application component is installed the following new Menu entry is available in the Administration menu: Localizations.

Translation Overview

The translation overview screen is designed to manage the translations. New translations can be created or existing translations
can be changed.

Once the translations are created or changed, the button Apply changes will store the changes in the database. Furthermore
the Messages bean will clear its cache and now serve the changed translations.

Initial Localization Import

The initial localization import is available to import the existing localization files (messages.properties) from the translations github repository.

The files from the translations repository have to be imported for every module and every language:

.
└── modules
    ├── core
    │   └── src
    │       └── com
    │           └── haulmont
    │               └── cuba
    │                   └── core
    │                       ├── messages.properties
    │                       └── messages_de.properties
    ├── desktop
    │   └── src
    │       └── com
    │           └── haulmont
    │               └── cuba
    │                   └── desktop
    │                       ├── messages.properties
    │                       └── messages_de.properties
    ├── global
    │   └── src
    │       └── com
    │           └── haulmont
    │               └── cuba
    │                   ├── messages.properties
    │                   └── messages_de.properties
    ├── gui
    │   └── src
    │       └── com
    │           └── haulmont
    │               └── cuba
    │                   └── gui
    │                       ├── messages.properties
    │                       └── messages_de.properties
    └── web
        └── src
            └── com
                └── haulmont
                    └── cuba
                        └── web
                            ├── messages.properties
                            └── messages_de.properties

Message Resolution

The application component extends the existing message lookup functionality in the following form:

It will lookup the message key in the database. If it is found, it will use that translation and cache the result
in the corresponding module (core / web).

If it is not found in the database, it will pass the message lookup on to the frameworks functionality, which will
then try to find the message either in the classpath (via messages.properties files) or in the config directory.

More information on the message lookup can be found in the CUBA documentation on Messages Localization.

Performance

Since the messages are lookup up from the database, the lookup takes longer then regular message lookups.
Furthermore it passes on message lookups on from the frontend layer to the backend layer, so that the DB can be taken into
consideration.

Practically this means, that in case a screen is opened up for the first time after the application server starts,
it will take longer to load. Once the screen was loaded, the messages are cached (either in the backend or the frontend),
which means that the speed from that moment on is back to normal.

In a phase of development, were a lot of application restarts occur, this slows down the runtime of the application.
Therefore it is a good idea, to turn off the application component during initial development phases.

Example usage

To see this application component in action, check out this example: cuba-example-using-db-localization.

2 Likes