True Multilingual URL's

[jacknails]

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?

[teppo]

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.

[Pierre-Luc]

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 (validator — registry). 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?

[LostKobrakai]

It would be nice to have those features and I would second your proposal of standardized language names. It's just consistent. 

[apeisa]

• One other thing that might be nice, is instead of letting language name be free-form, we could stick to BCP47 (validator — registry). 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).

[Pierre-Luc]

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.

[Gideon So]

It would be great to have this feature.

Gideon