Advanced Server i18n Configuration

WARNING: Configuration as described here is deprecated (from unblu version 4.2) and will not be supported in future versions. Please use dynamic configuration (stored in the database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via webapi-rest.

The information on this page assumes you have already read Server i18n Configuration.

In addition to the standard localized text settings mechanisms described in Server i18n Configuration, unblu has a set of additional localized text settings features that allow for more complex and dynamic setups.

Dynamic Reconfiguration

The collaboration server has the ability to dynamically reload configurations while the server is running.

Dynamic reconfiguration must be triggered explicitly by calling the /sys-unblu/rest/propertyCascade/reload rest service. If your server is running on localhost on port 8080, you need to request http://localhost:8080/sys-unblu/rest/propertyCascade/reload to trigger dynamic reconfiguration.

CAUTION: Make sure the /sys-unblu path is properly protected. (See Security Considerations.)

Dynamic reconfiguration also works for configuration settings. (See Configuration and Advanced Unblu Server Configuration.)

Scope-Specific Localized Texts

WARNING: File-based scoped configuration as described here is deprecated in will not be supported in future versions. Please use dynamic configuration (stored in database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via Web API.

Usually, localized properties are global to the unblu server, this means that a localized text property is always applied.

In addition to global configuration properties, unblu also provides a number of other scopes for localized text properties. Scoped localized text properties are only applied in a certain context, i.e., for a specific user or for a specific domain.

Scope-specific configuration is only supported if xml files (see XML Localized Text Files below) are used (instead of Java properties files).

The available configuration scopes are described below.

Global Scope

The global scope is the default scope. If you use properties files for configuration, the scope is always global. Globally-scoped properties are effective for the whole unblu server.

Named Area Scope

WARNING: File-based scoped configuration as described here is deprecated in will not be supported in future versions. Please use dynamic configuration (stored in database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via Web API.

The Named Areas scope is defined by the named area of the (web-) page the user is currently visiting.

User Scope

WARNING: File-based scoped configuration as described here is deprecated in will not be supported in future versions. Please use dynamic configuration (stored in database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via Web API.

The user scope is defined by the currently executing authenticated user. Using user-scoped configuration settings, you can specify individual configuration for users.

XML Localized Text Files

In addition to Java properties files, unblu also supports an xml-based localized text file format. Certain localized text features (such as scope-specific localized text, see above) are only supported in the xml-based format.

The xml-based format has the following general format:

<?xml version="1.0" encoding="UTF-8"?>
<!-- this is a generic example of an unblu xml localized text file... SECTION1 and SECTION2 must be replaced by valid section elements (global, domain or user) -->
 <localizedText>
    <SECTION1>
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </SECTION1>

    <SECTION2>
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </SECTION2>
 </localizedText>

The xml file must be a valid xml file starting with a <?xml version="1.0" encoding="<character-encoding>"?> line. We recommend using UTF-8 (like the sample above) but all other character encodings supported by the Java virtual machine in use are also supported.

The document element MUST be named "localizedText".

The document element can contain any number of sections where every section must be a valid section, as described below, and must be unique within the file.

Every section can contain any number of property elements but MUST NOT contain more than one property element using the same key.

Every property element MUST define a "key" attribute.

The value of the property is the text content of the property element.

Section elements must conform with one of the section types described below.

Section Type Global

The "global" section type defines properties that are valid globally (for the whole unblu server).

<?xml version="1.0" encoding="UTF-8"?>
<!-- example of an xml localized text file with a global section -->
<localizedText>
    <global>
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </global>
</localizedText>

The "global" section type does not have any attributes and MUST not be declared more than once in a localized text file.

Section Type "Named Area"

WARNING: file based scoped configuration as described here is deprecated in will not be supported in future versions. Please use dynamic configuration (stored in database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via Web API.

The "area" section type defines properties that are valid for a certain named area.

<?xml version="1.0" encoding="UTF-8"?>
<!-- example of an xml localized text file with a domain section -->
<localizedText>
    <area name="www">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </area>
</localizedText>

The "area" section type MUST declare an "name" attribute holding the name of the area.

A configuration file MUST NOT contain more than one area section with the same "name" attribute.

Section Type User

WARNING: File-based scoped configuration as described here is deprecated in will not be supported in future versions. Please use dynamic configuration (stored in database) instead. Dynamic configuration can be changed from the Admin Desk UI as well as via Web API.

The "user" section type defines properties that are valid for a certain authenticated user.

<?xml version="1.0" encoding="UTF-8"?>
<!-- example of an xml localized text file with a user section -->
<localizedText>
    <user id="123456">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </user>
</localizedText>

The "user" section type MUST declare an "id" attribute holding the id of the user the section is valid for.

A localized text file MUST NOT contain more than one user section with the same "id" attribute.

Example XML Configuration File

Example of a valid xml localized text file. Property key must be valid keys. (see Text Properties for real-life files).

<?xml version="1.0" encoding="UTF-8"?>
<localizedText>
    <global>
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </global>

    <area name="www">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </area>

    <area name="ebanking">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </area>


    <user id="12345">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>
    </user>

    <user id="abcde">
        <property key="key1.en">value 1 english</property>
        <property key="key1.de">value 1 german</property>
        <property key="key2.en">value 2 english</property>
        <property key="key2.de">value 2 german</property>  
    </user>  
</localizedText>

• deployonprem