Announcement Announcement Module
Collapse
No announcement yet.
AbstractBinaryConstraint (LessThan. GreaterThan, ...) and localization/messages Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AbstractBinaryConstraint (LessThan. GreaterThan, ...) and localization/messages

    I am currently trying to localize some binary constraints, which seems plain impossible. All descendants of AbstractBinaryConstraint (e.g. EqualTo, LessThan, GreatherThan, ...) are not localized via the Spring-RCP mechanisms.

    I wrote a exact copy of the class (deriving was impossible due to the structure of the original class), which implements TypeResolvable. Anyway, this had no effect on the error message. I then overwrote the toString-method, which brought my hardcoded messageKey into the GUI:

    Code:
    public class LessThanI18n extends ComparisonBinaryPredicate implements BinaryConstraint {
    [...]
    	public String toString() {
    		return "test.string.foo.bar";
    	}
    
    	public String getType() {
    		return "test.gettype.foo.bar";
    	}
    [...]
    }
    In combination with the pet clinic sample [add("birthDate", lt(new Date()))], this will bring the string "test.string.foo.bar" into the error message (in front of the current date).

    Anyway, entering a value for this key into the resource bundle had no effect. So I'm stuck right now, seems like I should file a bug report - or did I overlook something anyone of you already knows?
    Last edited by t0asti; Jun 11th, 2007, 11:29 AM. Reason: code fix & shortened message

  • #2
    All messages should be localized. The only difference when using typeResolvable is that the message key isn't the classname (starting with lowercase) but a custom one.

    So if you need localization on eg LessThan, you should check the messages.properties of spring-rcp. You'll find a line "lessThan=less than {0}", if you need this in another language, provide your own messages in a file which is named with the appropriate language/country. (eg messages_nl.properties for Dutch language).

    If you need some specific messages for some of your constraints, you should use TypeResolvable. Eg when you have "required=is required" in your messages, but at a certain place you need another message, then use typeResolvable.

    By the way, I think that all constraints should have the TypeResolvable support. I guess I'll change that one of these days.

    Kind regards,
    Jan

    Comment


    • #3
      Originally posted by [email protected] View Post
      So if you need localization on eg LessThan, you should check the messages.properties of spring-rcp. You'll find a line "lessThan=less than {0}", if you need this in another language, provide your own messages in a file which is named with the appropriate language/country.
      You are right insofar that the messageKeys are in spring-richclient-support, even in my local language. The problem is, these keys actually never get used for localization.

      You can reproduce it, if you just start the petclinic-standalone, edit a pet and change the date to one in the future. The message will look like "Birth Date Thu Jun 14 13:23:39 CEST 2007", while the entry in the messages.properties is "lessThan=less than {0}"

      The definition of the rule is in "org.springframework.richclient.samples.petclinic. domain.PetClinicValidationRulesSource" and looks like this:
      Code:
      add("birthDate", lt(new Date()));

      Comment


      • #4
        It seems that you've stumbled upon a bug. The translator is looking for messages in the correct Locale, but he's using the key 'parameterizedBinaryConstraint' instead of the 'lessThan' key. There's no special case in handling ParameterizedBinaryConstraints and thus this constraint is handled as an ordinary constraint while it should be handled differently (parsing should continue with the internal constraint).

        When using the parameterizedBinaryConstraint key, you do get a correct translation, but this is of course not the desired behaviour.

        I'll take a look into this and fix the problem. If there are any other messages appearing incorrectly, please let me know.

        Kind Regards,
        Jan

        Comment


        • #5
          I just updated my local copy and saw it was fixed in SVN. Thank you very much for your effort.

          Comment

          Working...
          X