Page names should follow page titles as much as possible, but still follow the other rules
Avoid repetitive page names in the URL path. This happens when a child page repeats the same word or a variation of it that is already present in the parent page name.
For example, instead of ../wiki-editor-toolbar/wiki-editor-toolbar-support, the proposed alternative is: ../wiki-editor-toolbar/support. Even if “support” is too generic on its own, having the parent wiki-editor-toolbar provides enough context for search engines to understand the full meaning.
Example: If the page title is “Choose a Syntax when Editing”, the page name should be choose-syntax-editing, but considering the fact that the parent is ../edit-page/, the page name should be ../edit-page/choose-syntax.
Note: This rule is feasible because the LD filters are based on the page title, not the page name, so avoiding repetition in the URL will not cause duplications in LD results.
Migration Strategy
We need to implement a name strategy for kebab-case and apply it to xwiki.org. This means that when a page is created, for example in this manner: “[[Developer Guide]]”, its URL will automatically be transformed into ../developer-guide. We need to ensure that this applies also to extensions pages created on Extension when new extensions are imported or added manually.
Initially, this strategy should be applied to:
All pages located in the new location on the main wiki.
Pages linked from the horizontal menu .
Pages linked from the footer.
When an existing extension page has been completely refactored into pages in the new “/Doc” space and the only thing that remains is a link to the extension doc, also rename the extension at that point.
Any new page created on xwiki.org after the proposal is accepted.
I do have a question though: since the URLs would not include stop words, it would theoretically be possible for the rules to push towards the same URL for 2 distinct pages (e.g.: whatever/a-something and whatever/the-something would both need to be turned into whatever/something, if I understand the rules correctly). What would happen in these cases?
Note that I’m certain that these would happen extremely rarely, if at all, but it is an edge case I thought of, so I wanted to mention it.
+1 for kebab-case. I’m less sure regarding stopwords as I think they could significantly alter the meaning, for example when negation is removed (but maybe having negation in page titles isn’t good, anyway?).
I assume that since you’re +1 for kebab-case you’re also +1 for Image names? I agree that negation stop words do affect the meaning, but most articles on URL best practices still recommend using kebab-case and eliminating stop words, and indeed negations are included in those lists. That said, I’m not entirely sure whether it’s a good idea to rethink a bit the list of stop words or to keep it as is.
Hi!
The status for this proposal is: Vincent, Pauline, Eleni, Simon, Manuel: +1. Michael is also +1 for using kebab-case, with the mention that we probably need to review the list of stop words around negations. The proposal seems to be agreed. The doc guide is updated at: https://dev.xwiki.org/xwiki/bin/view/Community/DocGuide#HPageNames.
Thanks!
Seems we missed doing this. I’ve discussed with @elenicojocariu and we’re going to rename all pages in the /Doc space (new doc).
Also, I’ve now enabled the “Preformatted Name strategy” on xwiki.org to get use closer from what we want. We still need to implement Loading... , Loading... and Loading... to be perfect.
So from now on, please remember to create new pages using the kebab style (and remove stop words + use lowercases only).
Note that if you rename important existing pages, make sure you create a redirect. Note that we won’t do this for pages in /Doc since they’re pretty new.
Thanks everyone. Let’s do it!
PS: For renaming lots of existing pages, we should probably write a script to perform the renames automatically.
So if I take the URL https://www.xwiki.org/xwiki/bin/view/Doc/XS/User/User/Profile/ViewUserProfile/AddAvatar/, it should be converted to https://www.xwiki.org/xwiki/bin/view/doc/xs/user/user/profile/view-user-profile/add-avatar/, right?
Yes, for consistency and SEO, everything should be lowercase.
BTW, I’m wondering about the page reference found in the information tab: the WebHome that’s added automatically is still in CamelCase. Should we consider changing that too for consistency? Note that it doesn’t appear in the URL, but it’s the page reference and only really visible in links when using the wiki syntax.
Note that in theory it’s already configurable through the reference.default.document property in xwiki.properties. I doubt we’ve ever tested it but it would be a good thing, to verify that we don’t have places where we still hardcode it.
Nobody replied but it’s a given for me that it should not apply to technical pages, at least not at the moment as this could cause bugs. Also there are parts of XWiki URLs that must stay as they are (e.g. using xwiki as the space name instead of XWiki would break stuff).
.