You are right, it should have been designed more simply, but at first UTF was an optional kind of plugin that we implemented without really knowing exactly what we were doing. :) We got a few good results early on--but also lot's of problems. So we began patching the problems one at a time. Only recently have I begun looking at the architecture as you suggested so I could put the conversions at just right places, only.
So the problem could be some patch to some problem, no longer needed. Or it could be something needed for some reason. Which is it? The list function sends its csv list (in your case, one utf name) to Display basically as an array of page names, and ultimately to the DoMarkup function, where it actually passes the list item as variable $page. And because it is supposed to be a page name, it converts to URL. As well as fixing various problems and doing all our special shortcuts replacements--all available in anything that does templating. Could we get rid of this filtering--well maybe, but it is kind of supposed to be a page name. Certainly the display engine typically responds to calls from a search function which gives it an array of actual page names. To change this function (pageshortcuts) is likely to cause numerous glitches. But then again maybe not. Perhaps we can get by with doing it in loadpage and savepage only, and link formation. We could try. But that kind of testing and debugging will probably have to wait until next week I'm afraid. We also will have to decide if we want to keep the utfpage: false option in site.config. which strips out all utf characters from page names. Imagine what that would do to a list function like this? Anyway,I've spend a good bit of time trying to track this all down, but the fix is not simple... It will have to wait till next week. I don't have a quick solution. In the mean time, you may just have to add a $query = BOLTurl2utf($query); line to your function. It won't hurt anything should I find a way to fix it, and you get instant functionality now. Cheers, Dan On Tue, Sep 22, 2009 at 5:34 AM, DrunkenMonk <[email protected]> wrote: > > I have, in the past, often had problems with conversions from or to > the url encoding. Either this not being applied for certain things, or > as in this case applied for absolutely no reason. I am currently > having difficulty because {+:title} return url-encoded strings: > > [(list "titleWithÖ" template=line)] > > [[#line]] > [(mysql user "SELECT * FROM table WHERE category='{+:title}'")] > [[#end]] > > The title is being recoded FROM utf-8 TO the url encoding. Feel my > pain: I generated the list from the same mysql table not 2 lines > prior. > > The whole thing is starting to annoy me. I mean, surely it would be a > simple matter to keep all internal boltwire encoding to the same > thing, changing only *from* the url-encoding when reading a url which, > I believe, is done at one place (?vars), and changing *to* url > encoding only when accessing a file-name (boltloadpage, boltsavepage) > or creating a url (don't actually know where this is done). Whenever I > call or recieve output from a boltwire function I should be certain > that I'm getting utf-8. Anything else is madness (as in, driving me > mad). > > I'm sorry if I sound a bit snippy. I just woke up, and was going to > cobble together the next stage of my project in 5 minutes before my > lecture, and once again had to deal with this. > > Seriously, writing multilingual plugins is something of a nightmare > for me right now, and I believe it shouldn't be. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
