Module LanguageLocalizedURL

[Soma]

  On 12/23/2012 at 6:57 PM, tiagoroldao said:

Well, this stopped for me when using tinyMCE, it happened only when using plain text, with no formatting... Sorry for the delay responding, I came across this issue during a project, one that ended up being a pain in the arse... And one that yielded nothing - clients from hell

The module doesn't parse plain text fields. Only Textarealanguage fields.

  On 12/23/2012 at 6:57 PM, tiagoroldao said:

Clarifying - this is a problem specific to a plain (no formatting) body (the "original") textarealanguage field. any other textarealanguage (not the Body) works ok.

I'm still not sure what should not work. It works well for all Textarealanguage fields, no matter what is called or where it is used. Every field if a href="..." found it will change it to be the right link in that language, prepend the /langcode/ etc. Tested back and forth.

  On 12/23/2012 at 6:57 PM, tiagoroldao said:

Anyhow, a different issue made me think of a possible feature - control over the field lang substitution behaviour.

When a field is called via the selectors, it is automatically translated to the other available languages, if it is empty.(right?) This may not be the desired behaviour (as when doing something like the echo (headline || title) behaviour ) is there a way to control this?

This is the behaviour of PW with languages and has nothing to do with this module. If an alternative language is empty it will fall back to the default.

I think you could try appending the language id to the field name if you explicitly want a language.

$langcode = $languages->get("de");
echo $page->get("headline$langcode|title$langcode");

[Soma]

Update to 0.1.1 information

- Changed the method to parseUrl and page rendering into the module. This is to prevent the infamous "double render" issue and also make it work with prependTemplateFile, appendTemplateFile config introduced in latest PW 2.3. (Skyscraper profile anyone).

- Added gatewayTemplate option in the module confiuration.

For this to work, the gateway template used to create the gateway pages /en/, /de/ etc, must be named to "language_gateway" (default) to make it work, or change the name in the module configuration to fit your template's name. The template file is now just a empty file and you can remove the code.

Thanks

[DV-JF]

Hey,

I`ve tried this module and everything works fine. Thx for the work!

Only thing I'm not able to activate ist a language switch. When I try this code:

  On 5/29/2012 at 10:23 AM, Soma said:

$lang = $user->language;
$langname = $lang->name == 'default' ? 'en' : $lang->name;

$user->language = $languages->get("default");
$st = $langname == 'en' ? " class='on'" : '';
echo $page->language_published->has($pages->get("/en/")) ? "<li><a$st href='{$page->url}'>EN</a></li>" : '';

$user->language = $languages->get("de");
$st = $langname == 'de' ? " class='on'" : '';
echo $page->language_published->has($pages->get("/de/")) ? "<li><a$st href='{$page->url}'>DE</a></li>" : '';

$user->language = $lang;

I get the following message:

Error Call to a member function has() on a non-object (line 59 of /homepages/20/d340034586/htdocs/web/site/templates/head.inc)
This error message was shown because you are logged in as a Superuser. Error has been logged. 

All I wan to do is display two flags, witch switch the language of the current page when clicked...

Any ideas?

Greets Jens alias DV-JF

[Soma]

Hello Jens

The problem seems you don't have the "language_published" page field added to your templates (as in manual). That's why it does the has() error.

echo $page->language_published->has($pages->get("/en/")) ? "<li><a$st href='{$page->url}'>EN</a></li>" : '';

This field is used to be able to "enable" a language or disable it. Since whe have only one page with multiple languages.

If you don't need this you could leave it out.

echo "<li><a$st href='{$page->url}'>EN</a></li>"';

[alan]

Forgive me for knowing very little about multi-language in PW yet, but I know I will need to use it soon...

I noticed that the LanguageLocalizedURL Module (brilliant, thanks for it ) notes that to do it's work inevitably involves a performance trade off.

Does LanguageLocalizedURL work with Pro Cache? If it does, is speed likely to be as fast as a similar site with Pro Cache and no LanguageLocalizedURL Module?

[diogo]

Alan, Ryan wrote this on the Pro Cache introduction post:

  Quote

There is a known issue when using ProCache with the LanguageLocalizedURL module. I hope to have this figured out soon, but for the moment you should not use ProCache in combination with that module as it doesn't appear to work in full.

[alan]

Ah; thanks diogo, I missed that.

From the little I've read it looks as if the LanguageLocalizedURL Module makes the job of building an SEO-safe, multi-lingual site all the more easy; so if Pro Cache will resolve any speed issue then those two Modules might make a great combo for many multi-language sites. Still only doing some cursory learning on this subject but I know I'll need to do it one day (living in a dual language country).

[Soma]

Unless you have not thousands of child pages in one branch I dont see much speed issues. Also theres options to add id to name which will allow even some more. Ive never used cacheing in pw and have some heavy sites I did not notice getting slow. Pw is fast and allows for scaling you might think it needs cache as with other systems.

[alan]

Thanks for that real-world info Soma; very encouraging. I looking forward to trying out LanguageLocalizedURL.

[Jorge Robles]

Hi all. Maybe is a dumb post, as I have not read the entire thread (my fault, I know).

I've just bumped with PagePaths module (still in beta in pw2.3).

As It builds and maintains a full page path index, I think it could be used with minimum effort improve the routing (in any language) to the page needed.

[Soma]

@Jorge, I don't understand, are you making a module PagePaths that stores page paths in db? For what usage?

Well unfortunately it wouldn't be useful, as the localized paths aren't same as page paths in PW but translated for each language. 

[Soma]

Ah now I get it, the PagePaths module by Ryan to query page paths. Still same as above holds true.

[Jorge Robles]

Sorry Soma, I have not explained well. PagePaths is a module built by Ryan for PW 2.3. I've just found on the dev installation while working.

Ok.. some Time Machine effect here.

[Raul]

Hello

Recently I have installed this extension but  i can't undestand because it doesn't work.

I have followed the instructions of: https://github.com/mcmorry/PW-language-localized-URL#readme

I have read all posts of this forum.

I have read the information about Multilanguage Suport of: http://processwire.com/api/multi-language-support/multi-language-fields/

But the extension doesn't work.

No errors, only 404 Page.

I have severeal questions about the documentation in Github:

1.- Create a new template "language_gateway" => That is:
   "I must to create ONE template called "language_gateway" or I must to create one template PER language with the name of the language. " 

   
 

    This can be silly, but  Soma commented: "Some common problem I think is that people forget to enable urlSegments on the gateway templates /en/ /it/."

   "What fields must contain this template?"
   "Need I a php file for this Template?" (here: http://processwire.com/api/multi-language-support/multi-language-fields/) it is explained using this php file.

2.- Create the pages of the website directly below the root page.

   I have the tree:
  

 - Home
    About
    de
    en

   The "About" page has Title: "About" and name "about"

   I use FieldtypePageTitleLanguage and the Title in German is "Ueber uns" but the name is equal "about"

   If I write into URL field of the browser: http://localsite/about => I recive a 404 error
   If I write into URL field of the browser: http://localsite/en/about => I recive a 404 error

   If I write into URL field of the browser: http://localsite/About => I recive a 404 error

   If I write into URL field of the browser: http://localsite/de/Ueber uns => I recive a 404 error

I can't more information to say because I don't recive more information from the system.

May be is the information unclear?

Thank you in advance

Raul

 

 

[Soma]

You must create only one language_gateway template and create the pages /en/ /de/ with it. It only needs a title field. Also you need to create a empty language_gateway.php file.

Enable urlSegments on that template too if you haven't.

The module will take the title to use as the urls segment, name isn't used. 

So urls would be:

domain.com/en/about/

domain.com/de/ueber-uns/

if you get a 404 on all those urls event with domain.com/about/, does the site work without language url module?

I think it would be good to have a profile with the module enabled and working for those wanting to start.

[Raul]

Hi Soma,

Thank you for the answer.

Yes, the site works without language url module.

But :
Why the urls are:

en/about/

de/ueber-uns/

I have only one page "About" and the name of this page is "about".

Than, What are "about" and "uber-uns" here?

If I understand right:
One thing is the Title, where I can write "About", "Ueber uns" etc. and another thing is the name of the page.
And there I can write only one Name => "about".

Must I create two diffent pages (english version and german version)?

Thank you and sory for my clumsiness

Raul

[Soma]

  Quote

jgarcia, on 05 Mar 2013 - 14:00, said:

But :

Why the urls are:

en/about/

de/ueber-uns/

I have only one page "About" and the name of this page is "about".

Than, What are "about" and "uber-uns" here?

If I understand right:

One thing is the Title, where I can write "About", "Ueber uns" etc. and another thing is the name of the page.

And there I can write only one Name => "about".

Must I create two diffent pages (english version and german version)?

Those two urls are the two language localized urls generated by the module using the language title for each language on the page. That's what the module is for.

It's the same page but different urls.

en/about/  => /about/

de/ueber-uns/  => /about/

So the language title is taken of the /about/ and not the name. Since there is only one name field, the module takes for example "Über uns" and runs it through sanitizer->pageName() to generate the url which then becomes "ueber-uns".

[Soma]

Is it possible you didn't see the "language_published" field to define published languages individually? Without this field it will throw 404 not found.

It's in the module setting at bottom:

"Page field name for defining the languages that are published. Create a field i.e. language_published of type 'Page'. Under Input > Selectable Pages, set the template to the one you use for the proxy pages. Set input field type to checkboxes. Set inputfield type to checkboxes. You also want to include a check in you selectors for navigation or lists to determine if a page in the current language is really published."

It's also explained in the readme here https://github.com/mcmorry/PW-language-localized-URL/blob/master/README.md#enabling-specific-pages-for-specific-languages

Though if this field is not installed/created to the templates, it will just show default language.

I'm also creating a little install profile with this module installed and working.

[Raul]

Hi Soma,

It works!!

Thank you very much.

I don't know exactly what I have made, but it works.

I think that i had forgotten to create the template "language_.gateway" because i hadn't read from instructions: "...introduced in PW 2.3".    (I use actually PW 2.2.9)

Sorry and thanks for the time.

Raul

[Soma]

Glad you got it working. I couldn't finish the export profile, as it doesn't currently work with multilanguage..

However I commited an update to the module and updated readme to make more sense.

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

[owzim]

I didn't work for me either until I read "Also you need to create a empty language_gateway.php file." in Soma's comment in here.

Now it works like a charm, great module.

I added a pull request on Github for this notice to be included in the readme. https://github.com/mcmorry/PW-language-localized-URL/pull/17

[mscore]

I have a problem with creating an access-restricted page and I suspect this module could be the cause.

Perhaps somebody with deeper knowledge could check this out?

I have installed and setup the language module and it works as it should as you can see here:

http://www.nordenswansiirila.fi/goer/

I need a password-protected page on a site and I have followed Ryan's instructions here:

http://processwire.com/talk/topic/355-best-way-to-deal-with-a-client-login/

To sum it up I have created a role "member" with "page-view" only, a template "member-page" with access to "member" only using the login option. Next I have created a page using template "member-only". Checking the access to this page shows that it should not be accessible to guests, only members. However, the page opens up sans login to anyone.

Member-only page "o":

http://www.nordenswansiirila.fi/goer/en/o/

Any suggestions?

[Soma]

This modules isn't aware of those setting as it uses it's own process to get and render out the pages.

I know it can be implemented and where, but it's not that simple as I'm also not aware of all settings and effects this would have...

I would consider using the new LanguagePageNames, which for sure will work in those cases. It's still in beta, but so is this module and not sure we're going to further maintain this module because it's now in core what this module implements.

[spoetnik]

I have got the module working, manually accesing the urlś work. I can't get your Language Switch to work. Any ideas?

It only displays the non-default language names, and these both link to the page with the default language.

[Soma]

I just setup my install to again use this module and copied the code you linked and it works "out of the box". It's hard to say without knowing/seeing what you got.

Also I don't know if you're aware that I recommend to use the new LanguagePageNames module now in latest core. Though it would be possible to switch later. Just so you know. LPN solves all drawbacks this module has and it was a workaround in the first place.