#7708 Reference wiki pages that contain spaces using underscores
It would be nice to avoid the ugliness of %20 sequences in wiki URLs for each space. One solution would be to allow the url to contain an underscore for each space character and still be able to find the page.
As for potential ambiguity in page names, either the wiki would need to treat the names as identical (so that ambiguous pages could not be created) or it would have to prefer finding a page with more underscore matches. I personally think that the former is preferable, which would mean that if I try to create a page named both "foo_bar" and "foo bar" that I'm told that the page exists. The alterntive is for a request for "foo_bar_baz" to find "foo_bar baz" in preference to "foo bar baz" if "foo_bar_baz" doesn't exist and the other 2 do (due to it having more matching underscores).
Related work for email addresses of wiki pages with spaces in them was done in [7a92cb]
Hi..
Agree. %20 in url looks ugly. But if we replace with underscore it will be displayed back with underscore too, (Since title will be saved with underscores). I checked by adding some characters like % and those things are also allowed for name. Do we need to do some validation for title?
If we really need underscore we can replace instead spaces when adding to db and also similarly we can do reverse work when we are displaying it
What is your idea regarding this?
I don't know offhand exactly what the right logic would be, but it does sound complicated and we'll have to test all the possibilities pretty thoroughly. It seems like it'd be nice to keep it as spaces in the database, since that's what really is intended. But then the code that handles URLs should accept either underscore or space, and probably the code that generates the links for wikis should turn spaces into underscores so that format actually is what people see. I might not be thinking of all the issues right now though.
I think % in a name is ok still, because with url-encoding that turns into %25
Hi..
Yeah agree. better go with current approach and it's not mandotory to use underscore because as you told URL encoding will do the rest