Jump to content

True Multilingual URL's


Recommended Posts

Each page in processwire has a name and a title.
When I create a new page and give it a title, the name is created automatically.
That name creates the URL of that page.
This works great for English sites.
However, for international users this doesn't work as nicely.

If I create a new page and give it a title that's not in English, then the name field is left blank and I must write a "fake" title in English.

I work with sites in Arabic and in Hebrew and this is the biggest difficulty I see when working on non English sites with Processwire.

Even for an experienced user, this is an annoyance every time.
For comparison, in WordPress I can have multilingual titles and URL's out of the box.
This is an advantage WordPress has when it comes to international users.

I would like to see this change, and perhaps help bring this change.

What would it take for Processwire to support multilingual URL's and page names?
What would be the best route to achieve this?



  • Like 5
Link to comment
Share on other sites

Hi there, @jacknails!

This thread over here might be worth checking out. Same subject, different name. Currently ProcessWire roughly follows the URI spec (RFC 3986), while what you're describing would require support for the IRI spec (RFC 3987).

+1 for this from me, though it doesn't seem to be very common need yet. This is probably the third time or so I've seen it asked for. Once there's enough need for it, I'm sure Ryan will take it into more serious consideration.

  • Like 2
Link to comment
Share on other sites

I think it's a good idea too. ProcessWire currently has one of the best multi language support I've seen, but there is room for improvement that I'd like to see too. For example:

  • I've submit a feature request/proposition to support UTF8MB4 in the database by default (would add support for emoticons). There is already some support for this, but by default the SQL loaded to create the basic pages needs to be changed manually.
  • One other thing that might be nice, is instead of letting language name be free-form, we could stick to BCP47 (validatorregistry). As an added bonus, we could package language packs for modules or else in a /lang/xx[-xx] format, instead of having to constantly install them manually. It would also make it possible for PW to set setlocale() by itself, without having to add it manually.
  • Default could have a way to set an alias, so that at runtime the language functions would recognize "en" and "default" as the same, for example. This would also be necessary for the second proposition.

What are your thoughts on this guys/gals? I think Ryan would probably be glad to receive a patch for this if it's of good enough quality, this could be a community effort. Should we open a new topic to discuss all that?

  • Like 2
Link to comment
Share on other sites

  • One other thing that might be nice, is instead of letting language name be free-form, we could stick to BCP47 (validatorregistry). As an added bonus, we could package language packs for modules or else in a /lang/xx[-xx] format, instead of having to constantly install them manually. It would also make it possible for PW to set setlocale() by itself, without having to add it manually.

I think both can be achieved: free-form language names and using language specific language packs for modules. There are certain benefits in not forcing only natural languages - I have used language support for client specific modifications for otherwise shared documentation for example.

I think the flow should be something along these lines:

  • When creating new language, UI recommends choosing real language from list (BCP47) or adding custom language name
  • Modules could ship their translations in /lang/xx-xx/ format and if there is match with xx-xx and any languages already found, those languages would be automatically applied for module.

There we would have both: convention (using standard languages) and flexibility (using languages for different use cases).

  • Like 3
Link to comment
Share on other sites

Valid point apeisa, though the BCP47 does already contain this, with the x- extension which is dedicated to private use.

I think this would be even more powerful, because it could use the base language as a fall back. For example fr-x-myclient > fr > default/en. That way you wouldn't have to maintain the whole translation strings, just the part you need to specify. I don't know if this would be overkill/technically feasible, but it's an option.

Of course free-form could work too, but I would propose like you do that each language be set using a dropdown list of predefined ones (to make support easier), and have a "Custom" entry where an input field would appear to set it as required.

  • Like 3
Link to comment
Share on other sites

  • 4 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By Crowdland Technology
      Hello everyone.
      I'm having some issues with Greek as default language, because the page name is not created automatically when enter the title of a new page. 
      Any chance to add support for it?
      I found this char mapping that might help on line 188
      Thank you!

      [EDIT]: A solution
      This was easier than we thought, we managed to find a solution by looking at how the sanitizer of page names works. 
      This is how the URL looks with this solution:
      For ProcessWire 3+ (what we tested) find Modules > Core > InputfieldPageName and under the “Character Replacements” Field you can add the mapping you would like.

      The replacement is not in the Core yet, so adding it for reference. The mapping is adjusted and simplified, and it follows the official Transliteration found here: https://en.wikipedia.org/wiki/Romanization_of_Greek
      Cheers to @PWaddict for also supplying an unofficial mapping and pointing us to the right direction 
      @ryan It would be great if this would be added to the Core sometime in the future and we can assist with further official mappings that are not present in this simplified version.
      Thank you!

      Elissavet from CrowdLand
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
    • By Sten

      I still did not solve my problem about Hebrew letters. In fact, it is ok for Russian for example to have a transliteration of characters (one to one) but in languages like Hebrew, Arabic, it is better to slugify with phonetic like here :
      use EasySlugger\Utf8Slugger; $slug = Utf8Slugger::slugify('日本語'); // slug = ri-ben-yu $slug = Utf8Slugger::slugify('العَرَبِيةُ‎‎'); // slug = alrbyt $slug = Utf8Slugger::slugify('עברית'); // slug = bryt So I am planning to insert https://github.com/javiereguiluz/EasySlugger
      Should I create a module or just add a hook ?
      I am a PW newbie.
      Thanks for your help
    • By Sten
      This is not directly about language module but I think I can get information from you.
      Can I add a vendor module to have all languages written automatically into name?
      I used this vendor module which is good with any language (hebrew, arabic...). How could I add it, so admin interface can use it ?
      Thank you
    • By bmacnaughton
      I am using the translation function (either $this->_() or __()) within a module that responds to AJAX API calls - there isn't really a page that is being served.
      When I supply a string with an apostrophe, e.g.,
      __('Book \'em danno') It is formatted as
      Book 'em danno  
      Is there some way to prevent output formatting when retrieving strings using the translation functions?
  • Create New...