On Wed, 23 Aug 2006 00:43:35 +0100 Chris Smith <chris@xxxxxxxxxxxxx> wrote: > I think this was to try and keep the links as readable as possible - > therefore trying to limit any entity encoding. What do you mean by readable? If one write ÎÎÎÏÎÏ this gets converted to "thl". In another case I got simple "n". So this conversion will actually provoke name conflicts I think. Also I don't see why one have to remove the numbers? > As I mentioned in the bug comment, there is a long term plan to > include the table of contents in the metadata. Page metadata is a > much smaller and more accessible file, making a fragment-id look up a > possibility. Still I don't find this a good solution for linking between pages and sections. > Right now the toHeaderLink() is applied indiscriminately to create > all header ids. I think it would be a good idea to match the > processing to the $conf[deaccent] setting - thereby allowing users of > languages with predominantly non-ascii characters to set $conf > [deaccent] = 0 and have virtually any character in their fragment > identifier. I can agree with that, but won't this break interwiki linking? Alternatively one could introduce a wiki syntax where one can supply a anchor. I mean it doesn't have to be for a section, but anywhere in the text. ===== Section that has a very very long title |#section87 ====== or [#some_achor#] or something like this. I'll have a look to see what other wikis do in this case. However I think that if one process the header to convert it for htmlspecial symbols (I mean convert & # space etc...) and then one can either convert it to lowercase or not and either convert to rawurlencoding or not. (I noticed that utf-8 page names gets converted with rawurlencoding). I don't see a problem with this approach. Keep up the excellent work Preben -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist