Sure, why not? I had the same problem with Slovak locale. Just send me the corrected (utf-8 encoded) file and I'll commit it.
-Matej Pierre-Yves Saumont wrote: > 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 > ------------------------------------------------------------------------- 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
