23 replies to this topic

[diogo]

But my question is: is there a public repositories of modules where to share it?

Not yet, but I suggest that you start a new thread specifically for this module in the Modules section of the forum.
Since Ryan liked your post we can be confident that it will get listed once it's finished

edit: on the modules section, maybe you could attach the module file to the post to make it easier to install

[mcmorry]

I released it here: http://processwire.c...gelocalizedurl/

I hope that it will be useful

[Soma]

Welcome mcmorry, and thanks for making this module.

The following is maybe more directed to Ryan, but everyone it welcome to think about something.

What would it mean to implement this feature in the core? Would it be a lot of work to change the url mapping to support language name for a page? (edit: or even possible or making sense). I mean since you already have implemented the multilang fields, and given that there's a page title multilang field, I find it now strange that such a module is required to implement language urls which is a "must have" feature, regarding SEO, for a good multilanguage site.

Sorry to bring this up here a little late. I just am thinking about this subject a very long time and not only since PW, but haven't really payed attention to the multilang field and title and that something seems missing as the "last" brick for a on-one-page multillanguage solution (with speaking urls) out of the box. I'm ever since using separate language trees to build sites and it works very well and flexible, consistent, fast, not so polluted page edit mask, etc. so I'm more the one heading towards the concept of Olivers language module with synced, linked multitrees. But this is a different subject and maybe discussed in the other room.

[ryan]

I think it's good to have this sort of functionality coming from a module. After all, all of ProcessWire's language support comes from modules that aren't installed by default. Multi-tree is the recommended way to build a front-end multi language site. The only reason multi language fields exist is because we needed a way to support in the admin while using the same page. It was just bonus that they can be used on the front end too. And perhaps they are revealing themselves to be useful enough on the front-end to warrant taking it further in the future. But multi language fields are very far from being a full solution, as only one field type of dozens supports multi language (FieldtypeTextLanguage, which is inclusive of FieldtypePageTitleLanguage and FieldtypeTextareaLanguage). I also don't want to start modifying and adding overhead to the core for features that aren't needed by everyone. This is what modules were designed for. So even if we do future expansion of multi language fields, I still think this is the role of modules. It's great to see what Mcmorry has done with this module, a lot of good thinking and ideas. If more and more people want to handle languages with fields rather than pages, I'm sure that the options will continue to grow.