[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

[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.

[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]

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.

[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]

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 Itaca,

that's a problem I'd like to tackle as well soon, but perhaps something for a new thread (@Isomorphic: Perhaps move #14/#15 to a new thread?)

For example:

• Temperatures: (id=1, shortName=hot), (2, mid), (3, cld), DataSource T_Temperature
• English: Hot, Medium, Cold
• German: Heiß, Mittel, Kalt

One solution I could think of is using PL/SQL (I'm using oracle) with nativeName="translate('T_Temperature', id, 'de')"

Problems here:

• How do I get the 'de' (=browser language) there? DynamicDSGenerator?
• Even if I cache the translations in a package on the DB, will the SQL / PLSQL context switches kill my performance?

Another solution: Use includeFrom="T_TemperatureTranslation.name_de"

Problems here:

• How do I get the 'de' (=browser language) there? DynamicDSGenerator?
• How do I actually translate? View? How do I define the view-columns? Oracle-PIVOT?
• Will the joining / pivoting kill my performance?
• Will having "TemperatureTranslation" for all my localizable DS be a heck of a maintainance-task?

Could you suggest a best practice?

Thank you & Best regards
Blama

[itaca]

Dear isomorphic,

The technique i18n for translating application tag and datasource name field is clear, but how would you recommend to implement database data translation inside the asynchronous ds call. Let say the datasource maps the following field with specific translation of a tag defined in the database name_en, name_de, name_fr. How could we switch to the right language in the datasource description.
I have experimented that the column name definition inside a datasource cannot be defined dynamically neither via a session variable or via a language tag <fmt> or <JSTL Core> in contrast to the column title that works,

Have you any thought how to achieve the data translation from database inside a datasource call.
Thanks,
Itaca

[Blama]

Hi Isomorphic,

sorry to bother here again. I read your last post and the changed docs, which now include:

Note that all whitespace is significant. A declaration like this one:
    <DataSource  xmlns:fmt="WEB-INF/" ID="i18nTest">
​      <title>
          <fmt:message key="dsTitle" />
      </title>
       ...
  </DataSource>
.. will cause linefeed / carriage return characters to be embedded in your title. This can be useful in situations where you want to embed small amounts of HTML in a localized attribute, but most of the time, you will want the <fmt> tag on one line with the surrounding tag (eg "title").

It seems we did not understand each other.
My problem is not with potential "\r\n"s or spaces in the resulting titles. The problem is that the title-placeholders do not get replaced.
My .ds.xml excerpt (note one space after opening title-tag):

<field name="MISSINGINFORMATION" length="35" type="text" escapeHTML="true" canSave="false">
    <title> <fmt:message key="missingData" /></title>
</field>

DataSourceLoader result:

{escapeHTML:true,validators:[],length:35,name:"MISSINGINFORMATION",canSave:false,type:"text",title:" [B]<fmt:message key=\"missingData\" xmlns:fmt=\"lmscompany/fmt\"/>[/B]"}

This ultimately results in an empty title, as the browsers interprets the fmt as an unknown (and also empty) html tag.

Best regards
Blama

[Isomorphic]

Ah, so these are requests to interlink the information to make it easier to find, not new sections. We've gone ahead and done this.

On the last point, it's not that whitespace is disallowed, it's that it's significant. It can be used to, for example, embed HTML in properties that allow it. We've noted this in the docs.

[Blama]

Hi Isomorphic,

thanks for the hint on RPCManager.setActionURL().

I meant the following additions to the docs:

• An additional HttpServletRequest parameter can be added to the condition() method for DMI-Validation message localization. Perhaps with link to validator.serverObject.
• An information on the RPCManager.setActionURL() you just mentioned. For DataSourceLoader it is clear that the parameter goes into the bootstrap-html file. For IDACall it is not immediately clear where to put the parameter.
• An information on the no-whitespace requirement for <title><fmt:message...-tags.

Best regards
Blama

[Isomorphic]

Use RPCManager.setActionURL().

It's not clear what you're suggesting should be added to the docs. The docs already suggest adding the locale parameter to force locale. We don't want to recapitulate Java basics like how servletRequest.getLocale() works.

[Blama]

Hi Isomorphic,

I saw this thread and your link to the docs there:

It obtains the user's Locale from the servlet request, but you can override this if you want to force an application-specific locale, regardless of the user's operating system settings. To do this, specify a "locale" parameter on HTTP requests to the DataSourceLoader and IDACall servlets.

While I now have a fully browsersetting-localizable application, a requested feature in the future will be to change the locale in the application. I'll then do that with DB-persisting per user and a cookie for the login screen.
As I imagine it, this will work for Login, the GWT application and DataSourceLoader-calls. But how do I permanently add a locale-parameter to the clientside RPCManager-requests?
This is needed for validator and DSResponse-failure l10n. I had a look at the methods there, but did not find something that looked like the solution.

Best regards
Blama

PS: I think all the information in this thread would be a good addition to the docs: HttpServletRequest for DSResponse-failure messages and the additional HttpServletRequest parameter for DMI validation messages. While this is part of the Quick Start Guide and one could know it, it is not part (and does not need to) of the DMI Validation sample. Same is true for the annoying no-spaces requirement in title-tags.
All these would be really valuable in the i18n-docs where everyone will search for it.

[Blama]

Hi Isomorphic,

thanks, just the information I needed!

Best regards
Blama

[Isomorphic]

condition() is invoked via DMI. After the first 5 required parameters, any of the optional parameters can be declared, including HttpServletRequest.