True, it's not % encoding, but close. I just substituted % for _ to get valid BoltWire page names. We may eventually get up to more standard % encoding but I want to take some more time to look into this and see how best to do it. That will require more system-wide changes but should allow us to get to full UTF page names. It may not even be too hard. I have some ideas, but wanted to get something out in the meantime for you. And this approach was quick and easy.
I also think we will be able to switch without any problems for your tag index, as the index is not encoded and the tag pages are dynamic. Glad to know how to do this now. The rest should be easy. Well, enjoy for now. Cheers, Dan On Tue, Feb 10, 2009 at 7:15 PM, Linly <[email protected]> wrote: > > Great thanks Dan, > > The utf-8 tagging is worked, partly. About displaying the utf-8 tags > it worked perfect. But in "action.tag.missing" display it decodes not > right. I got an url like this: > > http://localhost/?p=tag._c3_a6_c2_a8_c2_99_c3_a7_c2_b1_c2_a4 > > It's not %encoding. :( > >> At least the possibility now seems within reach as long as >> you don't mind LONG urls! > > Yes that is the cost I have to pay. > > Chees, > linly > > On 2月11日, 上午1時49分, The Editor <[email protected]> wrote: >> Hi Linly, I forgot that the BOLTutfstrip function only strips little >> things like accents and circumflexes off latin based letters, not >> full-fledge chinese characters! >> >> But I looked into the % encoding scheme a bit more and came up with a >> workable solution for you. And it may open the way for UTF page names >> as well. At least the possibility now seems within reach as long as >> you don't mind LONG urls! We already have simple stripping of links. >> We could beef it up to handle this kind of encoding >> automatically--both in the page shortcuts and in the {p} var >> generation, to make this almost seamless and transparent. That will be >> a bigger project, but I don't see why we can't do it. >> >> Anway, the solution requires the new UTF plugin I just released >> (formerly code that was in the library but not used in the system >> anywhere...) and a few changes to the info tagging markups. See this >> link for details--go down to the bottom of the page. >> >> http://www.boltwire.com/index.php?p=solutions.links.infotags >> >> I just did some quick testing, but it seems to work. Please do the >> ground work of letting me know if we need to fix anything. If all goes >> smoothly, I'll look into adding more automatic filtering of url's into >> the core code to give us more universal UTF8 handling. Perhaps going >> with straight %encoding most likely. >> >> Cheers, >> Dan >> >> P.S. I'll be releasing the next upgrade momentarily. You might want to >> wait for that, though I don't know there's anything dependent on it in >> the core. >> >> On Fri, Jan 30, 2009 at 11:09 AM, Linly <[email protected]> wrote: >> >> > Sorry Dan, bad luck. I use the newest 2.39 and carefully did exactly >> > what you write here but I can't get it to work. I still got the >> > "Invalid link." >> >> > linly >> >> > On 1月29日, 下午9時39分, The Editor <[email protected]> wrote: >> >> The problem is this line: >> >> >> [(list '{info.tags::{p}}' delimiter=' ' join=' | ' >> >> fmt='[[?tag.{+p}|+]]')] [ [[{p}&action=tags|Edit]] ] >> >> >> The {p} in the fmt part of the function uses the tag, which is as you >> >> note an invalid format. We could try stripping it: >> >> >> Try this (I didn't test): In config.php put: >> >> >> function BOLTFutfstrip($args, $zone) { >> >> return BOLTutf8_strip($args[''][0]); >> >> } >> >> >> Then in the function change it to this: >> >> >> [(list '{info.tags::{p}}' delimiter=' ' join=' | ' >> >> fmt='[[?tag.{+p}|+]]')] [ [[<(utfstrip {p})>&action=tags|Edit]] ] >> >> >> That should fix one part of the problem. Now however we have a new >> >> one: the stripped {p2} will no longer match the non-stripped tag. >> >> However we might be able to fix that by similarly stripping the tags >> >> when doing the searching: >> >> >> In infotags.php try changing line 5 to this: >> >> >> if (strpos($v, BOLTutf8_strip($args[''][1])) !== false) >> >> $outarray[] = $f; >> >> >> We'll probably also have to fix the tag cloud function as well. Perhaps: >> >> >> $out .= " <span style=\"font-size: " . $x . >> >> "px;\">[[?tag." . >> >> BOLTutf8_strip($i) . "|$i]]</span> "; >> >> >> Again, no guarantee about all this, but if it works, I'm willing to >> >> put the utfstrip function in the core and modify the infotags.php >> >> plugin. Can you test for me? >> >> >> Cheers, >> >> Dan >> >> >> On Thu, Jan 29, 2009 at 7:43 AM, Linly <[email protected]> wrote: >> >> >> > OK, I found the [(info)] function can find utf-8 tags and display the >> >> > page contain that tag. >> >> >> > Now the problem left is how not to make the "tag.utf-8tag" disply as >> >> > "Invalid link". >> >> >> > linly >> >> >> > On 1月29日, 下午6時20分, Linly <[email protected]> wrote: >> >> >> Just tested the new infotags plugin. It works great with one thing not >> >> >> so perfect that it does not support all utf-8 characters. Although I >> >> >> can set a Chinese tag for any page and it really appeared in page >> >> >> "info.tags", but it finally display as an "Invalid link." at the page >> >> >> footer. >> >> >> >> I know that is caused by the limitation of page name which can not >> >> >> allow none English characters. Is it means that if we need infotags >> >> >> support utf-8, we should wait the "Percent-encoding" which is an idea >> >> >> "not likely to make it into BoltWire 3.0"? :( >> >> >> >> What about if someone need utf-8 tags rather than making the tags >> >> >> become an url? Since we can write utf-8 characters into "info.tags", >> >> >> can we use the normal search function to find what page has a certain >> >> >> tag instead of using "tag.whatever" to find them? Because the >> >> >> "tag.whatever" way makes the utf-8 tags become "Invalid link." >> >> >> >> Cheers, >> >> >> linly >> >> >> >> On 1月22日, 下午11時18分, The Editor <[email protected]> wrote: >> >> >> >> > I've just release a new plugin using the info function to create a >> >> >> > tags system. As usual it's not the only solution, but I find this >> >> >> > particular approach very nice. >> >> >> >> >http://www.boltwire.com/index.php?p=solutions.links.infotags >> >> >> >> > It's much simpler and as I'm using it on my blog currently, it's more >> >> >> > likely to be supported, than the existing tags system which I would >> >> >> > consider deprecated. In fact, if there are traces of the code still >> >> >> > in >> >> >> > the core I will drop them on site... This approach is far superior >> >> >> > and >> >> >> > far more flexible. >> >> >> >> > The only thing I don't really like is the tagcloud feature is >> >> >> > generated dynamically on each page load. It seems it should be setup >> >> >> > as a command and generated only when the tags page is updated. >> >> >> > Perhaps >> >> >> > stored intact as a data variable on the info.tags. page. This would >> >> >> > increase performance and cpu load. It's plenty fast as is, but should >> >> >> > a site get busy every tweak we can manage will come in handy. >> >> >> >> > Will get around to it eventually. It won't be hard at all. Feedback >> >> >> > on the revised plugin info is appreciated. >> >> >> >> > Cheers, >> >> >> > Dan > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
