> 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
