concerning subst_blank_in_name: i have activated this for testing purposes on openacs.org, it seems to work fine (created a testing page). note, that it does not alter all page names on the fly, one has to edit a page such that the page name is altered. note, that this change does not alter the only the url, but as well the internal links (intra-wiki-links) and the page names.
using explicit language specifications. As others have pointed out there is a substantial difference between the navigational elements of the framework (labels on forms and buttons, error messages) and about content. while there is no doubt that for the navigational elements, content negotiation is very useful, i have doubts about the content language. when i have configured German as interaction language, but i would be completely unhappy to get for a link .../xowiki only the German version, especially when i am in an English page. the chosen language depends
- on the intentions of the page supplier,
- on the context where the page is used and
- on preferences of the user, and maybe
- on the availability on the system.
I see no way around having canonical URLs pointing to a page in a specified language, existing or not. i got as well the impression that you are unaware of the fact, that xowiki does language guessing already on many places, including urls.
Carl, what do you mean by the following sentence:
Any objections/suggestions before we start on this?
I do not want this to be hack either Gustaf.
i did not want to imply this: i am sorry, if it was possible to interpret my posting this way. i don't have the intention to make xowiki a clone of wikipedia (why not using wikipedia in the first place), but to develop xowiki into a more general tool in the context of a community system like openacs. There are several decisions made in wikipedia which i do not like (although they make make sense in wikipedia).
i see many places (maybe to many) where xowiki can be and should improved, also the url space (and the rp) belongs to this. i would certainly prefer a more object oriented way to tackle these problems. my point was that i see this discussion not in a state of: "here is what we want and we need somebody to implement it" but in a state where a deeper understanding of what's needed in what situation, and how does this fit with the current design is desirable.
