Module LanguageLocalizedURL

[diogo]

I like netcarver's idea. But there are also cases when the homepage is just a place where people choose the language. In this case, the homepage should be neutral, and mysite.com should be a different page from mysite.com/es

If some fix will be implemented, it would make sense to have these different situations as options on the module settings.

[netcarver]

Hi diogo,

If the language selection mechanism is made part of each page (eg, in the masthead as a drop-down selection) then perhaps redirecting a neutral homepage to a specific language home wouldn't be an issue, as visitors would always have the ability to switch from wherever they land in the site.

[diogo]

Yes, I agree, and this is how I would probably implement it. But this is a design issue, and would be great if the module would allow people to have their own design solutions instead of imposing one.

[netcarver]

Ah, I see. Yes, that would be more useful.

[mcmorry]

0.0.6 released. I added an option in the settings to disable the sub-folder for the default language.

[mcmorry]

I like netcarver's idea. But there are also cases when the homepage is just a place where people choose the language. In this case, the homepage should be neutral, and mysite.com should be a different page from mysite.com/es

If some fix will be implemented, it would make sense to have these different situations as options on the module settings.

The home page displays text in the default language, but you could always use Geo IP or browser language to choose for a different language. Just set it at the beginning of the home template.

In this case I suggest to add a select in your website to switch between languages. You should store the chosen language code and use it anyway in the homepage, ignoring your automatic language detection algorithm.

[landitus]

Mcmorry, i can't wait to try this out!!! Thanks a lot.

[diogo]

@mcmorry, this is not what I meant. I was referring to those situations when the landing page doesn't have any content, only the language choice. In this case would make sense to have it in mysite.com, and then the English homepage in mysite.com/en, and the Portuguese homepage in mysite.com/pt

[mcmorry]

@diogo sorry. I misunderstood.

[Nico Knoll]

I don't get it. How does the module know that /es/sobre/fondo/ belongs to /about/background/?

[diogo]

@Nico http://processwire.com/talk/topic/1310-multilanguage-urls-alias-creation/#entry11814

[mcmorry]

Supposing that you have created the proxy page /es, if you browse to that page (eg. www.mydomain.com/es/) the template of that page will ask the module to parse the url:

<?php
 $page = $modules->get('LanguageLocalizedURL')->parseUrl();
 include("./{$page->template}.php");
?>

The module will loop between all the first level pages and will see that the translated title of the page 'about' matches 'sobre'.

So it will continue searching between its children in the same way.

[diogo]

Oh, it's so different from what I posted! I didn't notice how the module is so different from it's beginnings

[Wanze]

Hi all!

I'm currently switching two projects from modx to Processwire - I have to say, Processwire is really awesome!!

My sites are both multilang, so I decided to test and maybe use this module. Everything's working fine so far, just noticed two things:

1)

I had a Page with the title "persönlich". Processwire generated a name "persoenlich" for this page, before installing this module.

The module now generates the name "personlich" (notice the missing e when replaced the Umlaut).

Looking into the "toSlug" method, I saw it uses the Santinizer::pageName method to generate the name. This method is using a replacement array from

the "inputfieldPageName" module. In the settings of this module, I was able to change "ö=o" to "ö=oe", now i'ts perfect ;-)

I was wondering why Processwire itself was not using the replacement array?

2)

Caching does not work.

There are no Page cache files generated or loaded when the module is installed.

I'm still exploring the architecture of Processwire and don't know exactly how the caching is handled.

Can anyone tell me if this is possible?

Maybe something like this (pseudo code), after finding the page to load:

$page = $modules->get('LanguageLocalizedURL')->parseUrl();
if($pages->getCache($page->id)){
 //return the output of the cached file
}else{
 //Check first if caching is enabled in template...
 $pages->cache($page);
 include("./{$page->template}.php");
}

[Soma]

Hi wanze and welcome.

Thanks for reporting and testing. We will look into it.

This module uses the same sanitizer page name translation as PW internally for pages. I'm surprized that "persönlich" would have been "persoenlich" without changing the replacements beforehand. I think you got tricked somehow.

[Soma]

2)

Caching does not work.

There are no Page cache files generated or loaded when the module is installed.

I'm still exploring the architecture of Processwire and don't know exactly how the caching is handled.

Can anyone tell me if this is possible?

Maybe something like this (pseudo code), after finding the page to load:

$page = $modules->get('LanguageLocalizedURL')->parseUrl();
if($pages->getCache($page->id)){
 //return the output of the cached file
}else{
 //Check first if caching is enabled in template...
 $pages->cache($page);
 include("./{$page->template}.php");
}

Well I tested it quickly. Since the caching seems to be handled by $page->render(), it makes sense anyway to use it for rendering the page instead of the include.

$page = $modules->get('LanguageLocalizedURL')->parseUrl();
echo $page->render();

This works with caching pages.

[mcmorry]

Thanks Wanze for reporting your experience and thanks to Soma for his fast reply.

I'll update the sample code for the language template so to use cache.

[Nico Knoll]

The module will loop between all the first level pages and will see that the translated title of the page 'about' matches 'sobre'.

So it will continue searching between its children in the same way.

But what I don't get is how the module can know that 'about' means 'sobre'. Is there any connection between translated files or how does it work?

[Soma]

@Nico, the module knows it because you have to enter it. We use the language page title field.

[diogo]

it's black magic

[Soma]

I found an issue with textarea fields if "Page Link Abstractor" module by Ryan is used to: "Convert root URLs and page URLs: Prevents broken links when linked pages are moved" ... as soon as I have an image or link in the text, it's not possible to open the page anymore. Looks like that feature can't be used with this module. Haven't looked into it further, but I think since we overwrite path/url the abstractor module hangs itself up. Not sure if there's a solution.

[Soma]

Next issue is also with setting links in tinymce. They will be inserted in the language the user has in PW admin. You would have to switch between languages in the admin to set them correctly for each language.

That again shows, that unfortunately this module/approach is still only a "hack" with lots of drawbacks, and mixes things up that shouldn't. So it still is not the first/best option for creating multilanguage sites imho. That's why I would have prefered a core solution to frontend multilang. But since Ryan isn't in for it, it would be much better to work on the multitree approach and make it more friendly to use in the admin.

[mcmorry]

Sad to see these problems. I don't know the "Page Link Abstractor" and I was not using the tinymce on multilinguage site. As soon I'll have little more time I'll try to understand what is the problem and to see if there is a workaround.

If Ryan will want to help or if he could find a different way to address this issues, it will be the best.

[diogo]

It's more than natural that this kind of problems will arise. This is not a simple module, but I think it brings great benefits. I never thought it would be so easy to build a multilanguage website in PW as it is with this, so I think the effort will pay. Still, the module shouldn't be considered nothing more than an alpha version, ant it will need lots of work and testing. And maybe a little help from Ryan

[Soma]

Next issue is also with setting links in tinymce. They will be inserted in the language the user has in PW admin. You would have to switch between languages in the admin to set them correctly for each language.

Referencing to this. I got through it and had to implement the language id of the tinymce field in about 5 core modules to get it to work. So it does, in the link dialog of tinymce, check if it is a language text field and give the language id through various js's,php's ... so if you add a link to a "german" tinymce language field the page list select is in german and returns the german url, and so on.

Edit: Of course this all isn't possible through a module or hooks at all.