Hi Matej, Of course I will test it as soon as you commit it. BTW, there are plenty of typos and spelling mistakes in the french script, and even an error in the abreviated day names (it says monday, tuesday, tuesday, thursday and there is no wednesday!). Do you want me to send you an edited file?
Pierre-Yves Matej Knopp a écrit : > Hi, > > I'm working on the date picker encoding problem. What I'll probably do > is to convert all non-unicode (latin1, ...) date picker locale strings > to utf-8 and add charset="utf-8" to the <script element that includes > the script. > > This should sove the problem, as xmlhttprequest (used to load script > during ajax header contribution) treats the response as utf-8. And the > charset in script that should ensure that during "regular" header > contribution the script will be loaded with the correct locale. I'll be > commiting soon, would you mind testing if it works for you? > > -Matej > > Pierre-Yves Saumont wrote: >> Hi Eelco, >> >> I did not feel irritated by your answers and I apologize for having >> let you think I was. I understand perfectly your position and I >> acknowledge the immense amount of work there is behind Wicket and I >> want to thank every one working on it for making such a smart >> framework available. >> >> I am building a demo/prototype application for a big french >> administration and I want to convince them that they should add Wicket >> to the list of their accepted technologies. That's why I need features >> that are 100% functionnal. If a feature is only 99% functionnal, it's >> probably better not to mention it because somebody will certainly >> pinpoint the 1% that is causing problem, making others forget about >> the working 99%. >> >> So, what I am trying to do is helping to find the cause of the problem >> and (may be) a solution. At this time, I am using a normal link to >> switch locales and I have removed all accented characters in the >> datapicker french strings and saved the file in ascii. I am working to >> find on a better workaround. >> >> Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it >> as been designed to suit the needs of english language applications >> where only a few exotic foreign characters have to be usable. It's >> main advantage is that the data is nearly the same size as ascci for >> this kind of use. I think UTF16 is a much better solution, even if it >> is not 100% perfect since it can't represent all characters needed in >> all languages. Next UNICODE encoding will be 32 bits, which will be >> enough for all characters of all languages in the galaxy. We will then >> have to design an extension for the rest of the universe ;-) >> >> Cheers, >> >> Pierre-Yves >> >> Eelco Hillenius a écrit : >>>> It is the same kind of problem we have with character encoding. Every >>>> time someone has a problem with encoding, the answer can be "use XXX >>>> encoding for all and there will be no problem". This is false AND >>>> irrelevant. >>> Well, I guess we hoped that UTF-8 would just work for everyone. It's >>> certainly advertised as that. But the message comes across, and the >>> more reports we have that something is broken, the harder we'll work >>> on it. It's just not all easy, and some of the bugs we are >>> encountering lately (like a problem with file descriptors) were not >>> our fault in the first place. We're not even sure the encoding >>> problems are. But the more people that actually use those encodings >>> can help us, possibly by supplying fixes/ solutions, the better. >>> >>>> It is irrelevant because the question is "how to use this >>>> functionnality" and not "how to do without it". >>> Yes, you are right. You have to understand though that a framework >>> can't fix every possible problem in the world. Every time we add a >>> feature, there's an open door for 10 additional ones. That doesn't >>> mean we don't want to add them, but maybe not now, or we need to be >>> convinced about the urgency of the problem. >>> >>>> It is false because it does not solve the problem. In the case of Ajax >>>> switching locale, remember the problem is updating the datepicker. If >>>> you switch the locale in a situation where no datepicker is displayed >>>> and then load a datepicker through Ajax, it is still broken. But of >>>> course, the solution is not to use Ajax. >>> Well we fixed header contribution through Ajax. It seems that the >>> datepicker is the component from hell, as we're having all kinds of >>> issues with it we don't have with other components. But Matej and >>> others spent many of his free nights trying to fix it and they have >>> been progressing very well. It's a pretty tough problem, really. >>> >>>> Or a slightly better solution: >>>> do not use Ajax to switch locales AND do not use anything else than US >>>> ASCII in the datepicker labels. >>> I didn't get the datepicker labels. Anything that has to do with the >>> JavaScript part that is faulty: I'm sorry but we can't do much about >>> it as we adopted that component from another project (jscalendar). >>> We're working on a replacement, and people can always create their own >>> replacement too (for intance, look at wicket-contrib-datepicker and >>> wicket-contrib-yui. >>> >>> I'm sorry you feel irritated by our answers. You are right that >>> telling you "you can't do that" is not a very satisfying answer. >>> Please understand that we are working our asses off in our free time, >>> un-sponsored etc to make this framework as good as we can, as fast as >>> we can. Keep those reports coming, and the best and fastest way to get >>> a bug fixed is to give us a solution for fixing it. >>> >>> Cheers, >>> >>> Eelco >>> >>> >>> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Wicket-user mailing list >> Wicket-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wicket-user >> > > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
