[Isomorphic]

The first thing to consider is why these translations are in the database at all. The translations for Hot, Medium and Cold are obviously not dynamic. Even if there is some legacy reason why these *must* be stored in a database, they could be turned into ordinary resource bundles, or turned into statically defined <valueMap> tags in a .ds.xml file, by a preprocessing step performed before deployment, and that's generally what we'd recommend.

So that leaves large, potentially runtime-modified translation sets. It's unclear if either of you actually have that scenario at all (as it's rather unusual). However, when it comes up, if we're looking at a set of record-specific translations, the database structure should store translations in a separate table, with "locale" and "message" as two of the columns. Here, you can use includeFrom to do the join, and you can inject the locale as criteria in a DMI or a custom DataSource.

You did mention a DB structure with separate columns per locale, which would obviously be very, very bad design for a large, dynamically modifiable set of translations. We're assuming that if that DB schema is real (and not just a made up example), you are in the simpler case mentioned above, where translations can be pre-processed into static resources.

[Blama]

Hi Isomorphic,

sorry for choosing a poor example or not explaining better.
The "temperatures" are more "levels" and are customer-defined. So they don't have to be hot, warm, cold necessarily.
The use case is to have customer-adminuser-defined entries that can be translated by the user into the languages I support. I think this means your "we're looking at a set of record-specific translations".
So I have to have them in the DB I think.
I did not think about your suggestion "inject the locale as criteria in a DMI", which IMHO should be the best way - before I thought about manipulating the includeFrom-value in a DynamicDSGenerator, but I like your suggestion better. I'll of course use your suggested DB-schema then. Thanks for the suggestion!



For other (static) cases I found a way to solve it, but I think that is not what you are suggesting. Example:
.ds.xml-field:

        <field name="TYPE" length="1" type="text" escapeHTML="true" required="true">
            <title><fmt:message key="wonLost" /></title>
            <valueMap>
                <value>W</value>
                <value>L</value>
            </valueMap>
        </field>

ListGridField-subclass:

    setValueMap(getWonlostValueMap());

    public static LinkedHashMap<String, String> getWonlostValueMap() {
        LinkedHashMap<String, String> vM = new LinkedHashMap<String, String>();
        vM.put("W", i18n.won());
        vM.put("L", i18n.lost());
        return vM;
    }
[B][/B]

This is working, but not what you suggested, is it?
In the .ds.xml-field-docs you have a valuemap with:

    <valueMap>
     <value ID="1">Pens & Pencils</value>
     <value ID="2">Stationery</value>
     <value ID="3">Computer Products</value>
     <value ID="4">Furniture</value>
     <value ID="5">Misc</value>
    </valueMap>

Is using <fmt>-translation tags allowed here? Is that what you mean by "they could be turned into ordinary resource bundles" in #16?

The other suggestion "statically defined <valueMap> tags + preprocessing" would not be multi-language anymore, would it?

Thank you & Best regards
Blama

[Isomorphic]

Yes, you can use <fmt> tags in <valueMaps> and that is indeed what we had in mind.

Pre-processing to create a resource bundle and then use <fmt> tag would be multi-language, assuming again that the translations are not modified at runtime. For your runtime-modifiable translations, we agree, use the approach of a related table that we suggested.

[carlossierra]

I'll dare join the conversation with an example of the last two posts. This is how I achieve a localized non-dynamic set of values in my DS:

<fmt:bundle basename="co.focuss.bmsim.shared.model.i18n.BMSimResources" encoding="utf-8"/>
<fields>

    <field name="username" primaryKey="true" canSave="false">
        <title><fmt:message key="users_userName"/></title>
    </field>
    
    <field name="password">
        <title><fmt:message key="users_password"/></title>
        <validators>
            <validator type="lengthRange" min="6">
                <errorMessage><fmt:message key="users_passwordMinimumLenghtValidator"/></errorMessage>
            </validator>
            <validator type="lengthRange" max="20">
                <errorMessage><fmt:message key="users_passwordMaximumLenghtValidator"/></errorMessage>
            </validator>
        </validators>
    </field>        
    
    <field name="language">
        <title><fmt:message key="users_language"/></title>
        <valueMap>
            <value id="en"><fmt:message key="users_languageEnglish"/></value>
            <value id="es"><fmt:message key="users_languageSpanish"/></value>
        </valueMap>
    </field>
    
</fields>

The first fields have localized title translations and simple validation messages. The last field has a set of values, stored in my DB by using short codes ('en', 'es'), but the values are displayed to the user in the appropriate language.

My sample AppResources_en.properties file (part of the language bundle) looks like this (these are just the tags for this specific DS):

# users.ds.xml
users_userName = User
users_password = Password
users_passwordMinimumLenghtValidator = Password length must be 6 or more characters.
users_passwordMaximumLenghtValidator = Password length must be 20 or less characters.
users_language = Simulator Language
users_languageEnglish = English
users_languageSpanish = Spanish
users_languageFrench = French

Just my two cents. I hope I'm not too lost here!

[Isomorphic]

Regarding a space before <fmt> tag causing it to be ignored by the localization system. This is fixed now and the support for text and HTML tags around <fmt> tag is added, see DataSource Localization docs for details. Note this applies to <fmt> tags used in a <valueMap> as well.

[Blama]

Hi Isomorphic,

<fmt>-tag plus suffix is working for me now. I have a non-html suffix (just some numbers), which is also working without CDATA.

Best regards,
Blama