Language based URL rewriting

Help / Discuss
,
2

Hello,

Just so that it’s mentioned here:

  • one technique that I have seen used in XWiki (and not only) for handling multiple languages, and which would also add the language in the URL is to have a subwiki for each language. This would easily make URLs like https://domain.eu/wiki/de/view/Public/Applications/iOS for the ‘de’ subwiki and the language used on that wiki will be the default language set in the preferences of the subwiki, which can be de.
    However, lots of the multilanguage features of XWiki are lost if you go for this content structuring approach: you won’t have the UI to change between the different translations of the same page easily, also, the UI that allows to easily create a translation for an existing document in a new language won’t be there anymore without customization, etc. So I guess it depends on your needs if this is a real solution for your case or not.

Now, to answer strictly the question that is asked:

  • first of all, from the point of view of XWiki the path has an indefinite number of components and after handling the first ones related to the path of the servlet, the “rest” is parsed into the reference of document to be fetched, with an unlimited number of spaces and an optional page name (…/A/B/C/D will be interpreted as document D in space C in space B in space A, with D being either terminal or non-terminal document, whichever exists).
    So, from my point of view, having the language particle “in the middle” of this reference part is complicating things more than anything, since, in order to avoid bugs, you need a way to handle the generic case and make sure that /de/ never ends up interpreted by XWiki as the space called ‘de’, regardless of the depth of the page hierarchy you may have.
    I would say that URLs like https://domain.eu/bin/view/en/Public/Applications/iOS are probably much easier to handle, with the /en/ particle between the action particle and the document reference parts, and quite equivalent to the one you mentioned from the pov of the need of having the language in the URL.

  • second of all, there is a way to use tuckey urlrewrite with XWiki, see here an example for simplifying the URLs https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/ShortURLs/#HUrlRewriteFilter and this method also alters URLs generated by XWiki, in addition to accepting different incoming URLs. So, in order to alter the URLs generated by XWiki you can try to go this way. This solution only involves modifications in the XWiki application, you don’t need to handle stuff at HAProxy level anymore, I would say.
    I have not done this specific case, but tuckey urlrewrite is a rather powerful tool, and it appears that, at least in the doc, it says that you can put a condition for a rewrite based on a cookie value UrlRewriteFilter - Manual so you should be able to handle the language part.

Hope this helps, let us know if it works for you.

Enjoy XWiki,
Anca