On Wed, 26 Jan 2005, IvorW wrote:
I am still poking at this issue, having got
distracted by the one
below, which I think is related but not the same.
Note that the page you get redirected to on a saved edit is wrong, being
This is because the node name parameter is not being properly URL-encoded
before the Location: header is printed to STDOUT. This bug slipped in
because I forgot that CGI::Wiki::Formatter::UseMod's ->node_name_to_node_param
method doesn't actually URL-encode, but expects you to do it yourself
after calling the method (this _is_ documented).
I think it perhaps should, since what I expect
from that method is
something I can bung into a URL and it will Just Work. However
changing it to do that would break backwards compatibility and could
lead to things being doubly-encoded, which would suck. Thoughts? I
may punt this to cgi-wiki-dev as well.
I wonder whether this might be the time to revisit node_name_to_node_param
and provide something more flexible. I have in mind something inwardly
pluggable that supplies a normalisation function for node names.
what do you mean by "normalisation",
it would be cool to support the "äöü" and others?
Currently, n_n_t_n_p reduces multiple whitespace to a
single space, replaces
spaces with underscores and adds Title Case. There is no reason why this
could not apply de-accenting of letters or turning umlauts into diphthongs.
I think that there is a strong case for this being a plugin.
please explain diphthongs.
i'm not a native speaker and dict doesn't know it either.
why de-accenting letters?
"café" should well be permitted as category.
Also, this could provide a solution to some of the
problem (I originally raised this as an issue with search, but it could
equally be thought of as a node name munging issue).
as i'm not familiar with the openguides code,
i may have misunderstood your statements.
i hope you'll find a solution for this encoding problem. :)