Sorry, I think I didn't make myself clear enough. I don't want to
translate just the "Required" key for several languages.
What I do is that I have several language specific text fields on the
same page, e.g. new LangTextField("name", model, Language.ENGLISH), new
LangTextField("name", model, Language.GERMAN). The user can enter the
"name" field in many languages with the different LangTextFields. (This
is the backend area. The user enters the texts in many languages and on
the frontend the text in the correct language gets displayed.) Based on
the language attribute of the text field a more specific "Required" key
should be provided.
The English properties files would look like:
RequiredEN=Please enter the field ${label} in English
RequiredDE=Please enter the field ${label} in German
For German:
RequiredEN=Bitte fuellen Sie das Feld ${label} in Englisch aus
RequiredDE=Bitte fuellen Sie das Feld ${label} in Deutsch aus
I don't think that can easily be achieved without overriding
reportRequiredError() (or the hack I described).
Christoph
Martin Grigorov (2012-04-10 09:40):
Hi,
The current impl of this method is just: error(new
ValidationError().addKey("Required"));
I.e. it just adds an error for this field and later the i18n mechanics
will use 'Required' as a key to find the actual message in the
resource bundles.
So you can provide several bundles for the different languages and
provide custom value for this key.
On Fri, Apr 6, 2012 at 12:37 PM, Christoph Leiter
<[email protected]> wrote:
Hi,
currently FormComponent#reportRequiredError() is a private method. Could it
be made protected to allow users to override the default implementation?
My use case is that I have a custom implementation of TextField that is
language specific. Instead of showing the user "Field X is required" I want
to display "Field X in language L is required". Currently I have to override
FormComponent#validate() and inline validateRequired() there just to be able
to provide my own implementation of reportRequiredError(), which is quite
cumbersome and brittle.
But if there's another, better solution, which doesn't need to make the
method protected, I'd be happy to hear it as well.
Thanks
Christoph
