mcmorry

Hi moreweb,

have you seen this page?

https://github.com/m...e-localized-URL

Try to follow the configuration steps written there.

Thanks

I've update the Authors list in the source code too

Hi, thank you for your suggestion.

I had some difficulties to find the documentation that you reported, because you was speaking about the "inline" documentation. Instead I was searching on online documentation where the steps are described in details:

https://github.com/mcmorry/PW-language-localized-URL#readme

Anyway I've fixed it as you suggested. It will be easier for all users to setup the modue.

Thank you

Thanks Soma for your updates. I merged your code on master. This is really an important improvement

I've seen that you already started to code the install procedure to create the template for proxy pages, but is commented out. Does it need more testing?

You are doing a grate job. I would like to have more time to help you, but currently I'm focused on too many projects.

Thanks again.

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.

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.

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 sorry. I misunderstood.

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.

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

Hi landitus,

I think that there is a problem in your case. Setting the default language to Spanish will create the homepage in Spanish, but ALL the other pages will be under /es folder.

I'll check if there is a way to add an option in the settings to have the default language without the language sub-folder.

Another thing that in any case you should consider, is to avoid duplicated contents. So if you add a language, prepare all the translations before to link them.

ops...

I've seen in the url /segment1/segment2/segment3 that was reported below. And I thought that they was listed as pages. Sorry... too late.... better if I go to sleep now

So, good to see that is working

0.0.5 released

I've seen the thumbnail... interesting bug. I'll add it as an issue.

ok thanks for testing it. I'll update the documentation and merge to master.

Next step will be to automate the installation process (include modules, prepare templates and proxy pages) and automatically sync the proxy pages when a new language is added/removed in the settings.

I will create some issue on github so it will be easier to track the progress and to collaborate.

ok I pushed on develop.

I'm not sure if there are problems with pagenums. I didn't test it yet.

Edit: it works correctly with deeper levels. I simply remove from urlSettings the first key the same amount of parents.

Yes I've found exactly what you told

I'll release it in few minutes.

Thanks Ryan! I'll try it now

Great!! Everything is working very well on a fresh PW install with only this module activated. The navigation and all the links of the default site with the original code unchanged work very well.

Suggestions for the Docs:

• instruction to check "Allow Url Segments" on the language template is missing.
  
• would make sense to suggest to check "Hidden: Excluded from lists and searches" on the language pages.
  

Thanks for testing it on default website. It's very good to know that it works without any problems.

About docs, you are right. It's better to include that two points. Thanks

I've been offline for the weekend since Friday, sorry to be stepping into the conversation late. I'll be happy to implement an unset function for url segments, but wondered if it should just unset, or should it also reindex the url segments that are remaining? For instance, if you have both urlSegment1 and urlSegment2 set, and you unset urlSegment1 should urlSegment2 take the place of urlSegment1?

Hi Ryan,

I'm glad to hear that you can introduce this method

Yes it's much better to reindex the segments. In this way the code inside templates remains compatible with the standard functionalities.

Thanks again.

0.0.4 released.

I've updated the documentation. I hope that it's easy to understand and use it.

I'm sure that there is space for improvement and some bad English to fix. If you find something to change don't hesitate to tell me

Ok never mind. I'm not the best in English. sorry

Anyway I've already added the method as you just suggested, but I've created a Hook with addHookProperty to the Page class to get the urlSegments.

I'm not sure if it's the best approach. Probably is better to access directly to the module method as you told.

I'll change it.

If later Ryan will be available to create the unsetUrlSegment it will be the best.

P.S. I've seen that there is a limit of 4 urlSegments, and of course if you have a deep tree of localized pages you could be very limited and tun soon in some problems. Do you know why there is this limit and if is it possible to change/remove it?

I didn't want to hook to a specific method, but I wanted to add a new property to that class.

How does it work when I want to create a new method or property using hooks to a specific object?

Of course I can't search for a function with "___" prefix.

EDIT: ... Probably the class should extends Wire. Is it correct?

Thanks for explaining in detail all these problems.

I have just release an update on master branch with new documentation.

Plus, I've also added a hook to the Page object to retrieve the adjusted urlSegments.

I tried to add the hook it to WireInput so to have

$input->mlUrlSegments

but it doesn't work.

Thanks mcmorry for the pull.

Thanks to you for your help

For next push it could be better to work on "develop" branch. So that the master will be updated correctly with documentation too.

Now I'll update the readme file to include the new features.

Of course it also contains the segments from the language root pages (/en/, /de/). But you can easily slice them of using the $page->parents count. So you end up with an array containing only the segments from the current page.

Why you think that is not good to implement this behavior directly inside the module? maybe with another configuration setting to disable it.

There's some things to account for if using this module, and it has various side-effects , but so far most of it can be worked around with the excellent and system and simple API. I think for simple multilang sites, it will work quite well. I wouldn't recommend doing a big and complex site using this approach yet.

Could you give more info about this? What kind of side-effects it has? And why you wouldn't recommend it for big site?

Hi Diogo,

thanks for your suggestions.

I've just updated the github repository (https://github.com/mcmorry/PW-language-localized-URL) with the last changes from Soma.

Almost all your suggestions has been implemented.:

• $page->url instead of $page->mlUrl()
  
• the use of id based on the module settings
  
• support for urlSegments. Thought the segments are not automatically readjusted. (on this I have to check better)
  

I'll wait for your feedback.

Mind creating a repo on github for this module, so we can collaborate more easily on this? (If you want, I could create one on my account.

I created it : https://github.com/mcmorry/PW-language-localized-URL

The slug method can be changed to:

public function toSlug($str) {
$str = mb_strtolower($str); // needed for uppercase cyrillic chars
$str = $this->sanitizer->pageName($str, Sanitizer::translate);
return $str;
}

Yes it works perfectly.

I also changed the hook to

$this->addHookAfter('Page::path', $this, 'mlUrl');

So the system internally also works, and no change is required to use mlUrl. It works great so far.

I tried it, but the administration get broken. It tries to load everything with /en/ when loading the list of pages. Did you resolved it already?

I'll try to understand better what is wrong.