Hi I'll have a Norwegian translation ready later today :)
Hermod -----Opprinnelig melding----- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Craig McClanahan Sendt: 12. desember 2006 06:56 Til: [email protected] Emne: Re: <s:commonsValidator> question On 12/11/06, JS Portal support team <[EMAIL PROTECTED]> wrote: > > >If you do not specify messages for these keys in your own application > >resource bundle, validator will fall back to its own default message > >strings ... so you don't have to override these unless the defaults do > not > >help you. > > Does shale also internationalize these messages then? Also in Hebrew and > Korean or any other script for that matter? At the moment, Shale only includes the English and German translation of the messages. But I would love to check in translated versions if I could find some volunteers to do the translations! It's a matter of providing an appropriate messages_XXX.properties file containing translations of the English version, which can be found at [1]. The same applies to any other message resource bundles found in the source base as well. The best way to provide the translations would be to create an RFE issue in our tracking system[1], and add the appropriate properties files as an enhancement. Like all resource bundles, don't forget to run native2ascii if the translations include on-USASCII7 characters. >That is what would happen if the form is actually submitted, but the client > >side checks are designed to prevent the form submit from happening if > there > >are any errors detected there -- so things never get far enough along for > >the server side checks to kick in (unless you've disabled client side > >Javascript). > > Why I asked is because I want to use the client check to prevent > unneeded return trips to the server. I just don't like the looks of the > alert. I was hoping shale also made a little client script available > which populates the h:message with the appropriate error message. That would be a great enhancement to the current functionality, but it's not there at present. It's also going to take a bit of refactoring in the client side JavaScript code of Commons Validator, which currently mixes the logic (is the field valid) and presentation (do the popup) a little too closely to be able to pull this off. But the developers there have been receptive to such changes. Thank you for your help,= Craig [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/ resources/org/apache/shale/validator/messages.properties?revision=467172&vie w=markup ]2] https://issues.apache.org/struts/browse/SHALE JS Portal - Support > Dasstraat 21 > 2623CB Delft > the Netherlands > E: [EMAIL PROTECTED] > W: www.jsportal.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig > McClanahan > Sent: Tuesday, December 12, 2006 12:36 PM > To: [email protected] > Subject: Re: <s:commonsValidator> question > > On 12/11/06, JS Portal support team <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I have two questions concerning <s:commonsValidator> tag > > > > 1. Is there a way to set the message attribute of the s:commonsValidator > > with the value resulting from?: > > > > <h:outputFormat escape="false" value="#{labels['err.requiredField']}"> > > <f:param value="#{labels['labels.user.email']}" /> > > </h:outputFormat> > > > > This way I don't have to add a long list of err.required.email, > > err.required.name etc. to my i18n properties files. Just a compilation > > of my err.requiredField ({0} required) combined with the field name will > > be enough. > > > If you do not specify messages for these keys in your own application > resource bundle, validator will fall back to its own default message > strings ... so you don't have to override these unless the defaults do > not > help you. > > 2. Is there a way to have the client check also print the error message > > to the <h:message for="myField"/> in stead of having the JavaScript > > alert pop up? > > > That is what would happen if the form is actually submitted, but the > client > side checks are designed to prevent the form submit from happening if > there > are any errors detected there -- so things never get far enough along for > the server side checks to kick in (unless you've disabled client side > Javascript). > > Thank you and have a great day, > > Joost Schouten > > Director > > > Craig > > > JS Portal > > Dasstraat 21 > > 2623CB Delft > > the Netherlands > > P: +31 6 160 160 14 > > E: [EMAIL PROTECTED] > > W: www.jsportal.com > > > > > >
