Internationalization and rule definition file issue

[Guillaume Boivin]

Hi,

Consider this rules definition xml file :

<?xml version="1.0" encoding="UTF-8"?>
<validateThis xsi:noNamespaceSchemaLocation="validateThis.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <contexts>
        <context name="Register" formName="frmRegister" />
    </contexts>
    <objectProperties>
        <property name="lname" desc="Last name">
            <rule type="required" contexts="*"/>
        </property>
        <property name="fname" desc="First name">
            <rule type="required" contexts="*"/>
        </property>
        <property name="email" desc="Email">
            <rule type="required" contexts="*"/>
            <rule type="email" contexts="*"/>
        </property>
    </objectProperties>
</validateThis>

When I omit to enter the lname field with locale en_US I get the default error message : The Last name is required.

So far so good.

When I use the fr_CA locale tought there is no way to specify another description for the placeholder {1} that gets used to generate the failure message. So we get this failure message : Le champ Last Name est requis.

The issue is : We should be able, when something in the rules definition file is used directly in a failure message to specify in wich locale it should be used. As it's gonna inevitably break internationalization of failure messages and render this function pointless.

The two solutions I got right now are :

• create 2 rules definition, one for english and one for french that are exactly the same except for the desc attribute of rules properties (creating a maintenance nightmare).
• Manually dwelve in the code to change things around.

I would be interested in helping this framework on this issue but I would need a bit of help from your side to get a hang of the complete process.

thks

[Dominic Watson]

Yes, ideally the description for each field, when using a translator, should be derived from something like:

translate( fieldDescription, locale );

Then, in your xml, have something like:

<property name="lname" desc="resource.bundle.key.for.lname">

I'm only just now looking at implementing l18n though, so perhaps it does this?