[Isomorphic]

Hi,
After some investigation, it turns out things are actually behaving as they should in our testing, and problem you're experiencing is most likely a configuration error. We apologize for the conflicting information.

To show you a test case where this is behaving as it should - let's start with the "BuiltInDS" sample from the SmartGWTEE 4.1p package.
For completeness, let's show both framework localization and localization of custom values within the .ds.xml file - in this case the error message for a validator.

Everything we're doing here is covered in the javadoc - see the Framework localization overview and the DataSource localization overview. (We're not getting into other application-level localization, but for completeness we recommend standards GWT localization techniques as discussed here)

To start with let's modify the BuiltInDS application to enable framework localization:
- modify the BuiltInDS.gwt.xml file to enable the "fr" locale as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.5.1//EN"
   "http://google-web-toolkit.googlecode.com/svn/tags/2.5.1/distro-source/core/src/gwt-module.dtd">
<module rename-to="builtinds">
    <inherits name='com.google.gwt.user.User'/>
    <inherits name="com.smartgwt.tools.SmartGwtTools"/>
    <inherits name="com.smartgwtee.tools.Tools"/>
    <inherits name="com.smartgwtee.SmartGwtEE"/>
    <entry-point class='com.smartgwt.sample.client.BuiltInDS'/>
    <extend-property name="locale" values="fr"/>
</module>

Now you can either add the "locale=fr" param to your browser when loading the app: http://127.0.0.1:8888/BuiltInDS.html?locale=fr, or you can add the meta tag to your bootstrap's source: <meta name="gwt:property" content="locale=fr">

Now if you load the application, you'll see the empty message before you select a DataSource from the grid on the left is localized to French.
If you select "Office Supplies" and then click the "New" button, followed by the "Save" button without entering any details, you'll see the validation error displayed next to the "Item" item is localized ("Champs Requis" rather than "Field is Required").

Now lets add a validator to the xml file with a custom error message, and localize that:
- create a new pair of .properties files in your source tree.
We created "i18nMessages.properties", containing the following:

#custom properties file for 'i18nMessages'
validator_requiredField = Required Field Custom

and "i18nMessages_fr.properties", containing this:

#custom properties file for 'i18nMessages' - french version
validator_requiredField = Champs Requis Personnailise

You can put these wherever makes sense for your app - we put them in the com.smartgwt.sample.client package.

Now modify the supplyItem.ds.xml file to include the "fmt" tags necessary to pick up this locale information. Note the <fmt:bundle... > tag refers to the correct location for the localized files:

<DataSource  xmlns:fmt="WEB-INF/"
    ID="supplyItem"
    serverType="sql"
    tableName="supplyItem"
    titleField="itemName"
    testFileName="/examples/shared/ds/test_data/supplyItem.data.xml"
    dbImportFileName="/examples/shared/ds/test_data/supplyItemLarge.data.xml"
>
	<fmt:bundle basename="com.smartgwt.sample.client.i18nMessages" />
    
    <fields>
        <field name="itemID"      type="sequence" hidden="true"       primaryKey="true"/>
        <field name="itemName"    type="text"     title="Item"        length="128">
            <validators>
                <validator type="required" requiresServer="true">
                    <errorMessage><fmt:message key="validator_requiredField"/>
                    </errorMessage>
                </validator>
            </validators>
        </field>
        <field name="SKU"         type="text"     title="SKU"         length="10"        required="true"/>
        <field name="description" type="text"     title="Description" length="2000"/>
        <field name="category"    type="text"     title="Category"    length="128"       required="true"
               foreignKey="supplyCategory.categoryName"/>
        <field name="units"       type="enum"     title="Units"       length="5">
            <valueMap>
                <value>Roll</value>
                <value>Ea</value>
                <value>Pkt</value>
                <value>Set</value>
                <value>Tube</value>
                <value>Pad</value>
                <value>Ream</value>
                <value>Tin</value>
                <value>Bag</value>
                <value>Ctn</value>
                <value>Box</value>
            </valueMap>
        </field>
        <field name="unitCost"    type="float"    title="Unit Cost"   required="true">
            <validators>
                <validator type="floatRange" min="0" errorMessage="Please enter a valid (positive) cost"/>
                <validator type="floatPrecision" precision="2" errorMessage="The maximum allowed precision is 2"/>
            </validators>
        </field>
        <field name="inStock"   type="boolean"  title="In Stock"/>
        <field name="nextShipment"  type="date" title="Next Shipment"/>
    </fields>
</DataSource>

What we've done here is added a new "required" type validator to the itemName field, and included a custom (localized) error message.
Now modify the bootstrap file (BuiltInDS.html) to actually apply the french locale to the dataSource when loading it, changing this:

    <!--load the datasources-->
    <script src="builtinds/sc/DataSourceLoader?dataSource=supplyItem,animals,employees"></script>

to this

    <!--load the datasources-->
    <script src="builtinds/sc/DataSourceLoader?dataSource=supplyItem,animals,employees&locale=fr"></script>

Now load the app (note you may need to do a GWT compile to pick up the new resource bundle), and repeat the same steps - click "Office Supplies" from the list on the left, then hit the "New" button, then the "Save" button without populating any field.
Now you'll see the modified, localized error message "Champs Requis Personnailise'

Please let us know if this doesn't fully resolve this issue for you

Thanks
Isomorphic Software

[Isomorphic]

Just a follow up to let you know we are reproducing the problem and a developer is working on a solution. We anticipate being able to get a framework change in to address this very soon.

Regards
Isomorphic Software

[Isomorphic]

Hi Th. Gilbert,
Please rest assured we are working on this and will follow up as soon as we have more information

Regards
Isomorphic Software

[tgilbert]

This starts getting critical for us, we had to move to a recent build to have some other tickets solved and we are now facing a couple of regressions. As the application is fully localized, this is big concern and we would really appreciate it can be solved asap in a stable release.

Regards,

Th. Gilbert

[agalataud]

Hi

See my last screenshot. Both 'required' validators are showing duplicate localizations.
In my test case, and in our application, we have enabled fr and en locales in gwt.xml.
I reproduce the problem when setting locale to french (query parameter locale=fr or meta tag gwt:property to fr). I shows 'Field is required' and 'Champ requis' in the same tooltip

Antoine

[Isomorphic]

With your test case, which of your validators are showing duplicate and/or wrong locale error messages?

You have a required="true" declaration, which implicitly is a validator of type="required". It has no errorMessage defined, so it will show the framework default message. That will still be localized if you have set the GWT locale of course.

[agalataud]

That all said, this is an incomplete test case (no SQL Schema, no resource bundle), but since you're having so much trouble here, we'll make the mods necessary to the sample project and show you what an appropriate test case would look like (dead simple, and easier than what you've done).

That would be very kind of you. Thanks in advance.
Note: with sqlschema and resource bundles (+gwt.xml) it's pretty much what was included in the project I wanted to send you

Now our project is close to a deadline, I'd really appreciate progressing in the resolution of this issue. Let me know asap if you are able to reproduce or if you still miss something.

Regards
Antoine

[Isomorphic]

When providing a test case, I need to ensure it's as simple as possible, but also as close as possible to my situation.

No, nothing of the kind is required. The sole requirements for a test case are that it reproduces a bug and is simple.

When you see a problem in your app and you believe it's a framework issue, the most efficient thing is just to grab a sample and modify it to show the problem.

There is no reason to try to closely replicate your environment. That's just wasted time.

That all said, this is an incomplete test case (no SQL Schema, no resource bundle), but since you're having so much trouble here, we'll make the mods necessary to the sample project and show you what an appropriate test case would look like (dead simple, and easier than what you've done).

[agalataud]

When providing a test case, I need to ensure it's as simple as possible, but also as close as possible to my situation.
In the end I need the bug affecting the feature I'm using to be fixed.
Moreover, I guess that even if I provide a .ds.xml referring to a SQL table, it doesn't take much time to mock this up.
Finally, I don't have in mind all the features of the framework, so finding an identical-but-simpler feature to demonstrate isn't necessarily the easiest approach for the reporter. Again, I think you're on the good side to apply such approach.

About the bug itself: here I provide a .ds.xml because it's how I reproduce the bug and I believe the use of JSTL-like internalization (fmt:) in it could be part of the problem.

[Isomorphic]

No, this is our method for saving you time.

Typically, when a user tries to use a complete Java project as a test case, it contains many, many issues: hardcoded paths, need for databases to be present and certain database tables to exist, third-party library dependencies, only works with certain IDEs, etc.

A huge amount of back and forth is then required to get the project to actually run - and historically the result has been that the problem wasn't with SmartGWT after all, so all the effort spent working through project setup issues was pointless.

Creating test cases by modifying the sample projects is just a much more effective process. It naturally isolates the problem to SmartGWT and there is zero wasted effort on either side.

As a specific example, you mention your test project includes a .ds.xml file. Setting this up was likely a waste of time; starting from the builtinDS sample project you would have had a working DataSource with database table and sample data already present, and could have focused on just adding whatever settings are required to replicate the problem.

Since I reported this issue (1 month ago), I haven't seen any effort on your side to try at least a simple test case.

?? where is this assumption coming from?

You realize that what you're currently claiming is that validators just show mixed-language messages any time they fail? You can trivially verify, as we did, that this doesn't happen in framework samples, since you can switch the locale in the Showcase and just try it.

More generally, on your other bugs, we either tried the corresponding Showcase example, ran the corresponding automated test just in case, or indeed, wrote some quick test code to check on your claimed behavior.

The problem is that there is typically some unusual detail on your end that is actually causing the problem, and this is true for both framework issues and errors in your code. Once we've tried to replicate a problem and not been able to, we need to see your actual code to be able to make further progress.

[agalataud]

I will provide what you want tomorrow.

Just to let you know my disappointment with support on this issue and other recent issues some colleagues and I reported.
I find it unbelievable that you refuse a sample project with nothing more than what you're asking (a java, a ds.xml and 2 properties files). What's the point of asking seperate uploads?
Since I reported this issue (1 month ago), I haven't seen any effort on your side to try at least a simple test case.
Same scenario with other issues reported: I had to insist with several posts, finally giving you test cases of almost 20 lines i believe you could have produced in 10'minutes.

Is your method based on discouraging people?

[Isomorphic]

In general, do not use a complete project as a test case. Many, many things can be wrong with a project that are not flaws in SmartGWT.

Instead, just show the modifications needs for a standard SDK to reproduce the problem - generally this means just one .java file with an onModuleLoad() definition, which can replace one of the .java files from a sample project such as BuiltInDS.

[agalataud]

I've been able to reproduce the duplicate validator message problem ('Field required' and 'Champ requis' both displayed) in a test project I started from scratch.
Basically only a form, 1 data source and french and english language packs.

Is there a way to send you the .zip of the eclipse project?

Also find attached a screenshot showing the pb in this test case.

Regards
Antoine

[Isomorphic]

Sorry, we really can't do anything further with just another screenshot of an issue happening in your app, and unfortunately, the JavaScript state you're inspecting is just 1-to-1 with the screenshot, and doesn't suggest anything about how your application gets into this state.

What we would suggest is coordinating with this other developer from your team, who is attempting to work on "dynamic localization" for your application.

Whatever changes and/or subsystem have been introduced with this goal in mind are almost certainly responsible in some way for the weird behavior you're seeing, which has never been reported by another user, and is virtually certain to result from some kind of misuse of the GWT or SmartGWT localization APIs.

[agalataud]

Hi

We're currently running with nightly build 2014-06-14.

Here is a clear example of duplicated localization with a standard validator.
We have 2 languages supported, french and english.
When using SmartGWT required validator, localization is performed by SmartGWT using its own resources.

As you can see in first screenshot, both english and french messages appear.

I tried to debug in JS a bit (2nd screenshot), and watching some values in isc_DynamicForm_validate, I've found that field variable contains all translations of validator message (reported as _21.$79u in watch list) but error reported by validator execution contains only the right translation (here french - see _26.errors).
This may be a dumb shortcut but, why validator execution results aren't used to fill tooltip?