Multi-language page names / URLs

[kixe]

Cannot get the field 'name' in the current language. Example:
 

$pages->get('/sitemap/')->name
 

puts out 'seitenuebersicht', the default name, even if I switch to another language. In contrast the following api is working fine and puts out the current language.

$pages->get('/sitemap/')->title;
 

Is there a special reason of this? (I am using latest wire from dev-branch)

[Soma]

Name is a special property not a field same as other fields, so you need to tell it what language you want.

echo $page->localName($user->language);

or 

echo $page->get("name$user->language");

[wishbone]

is this module already included in the stable 2.3 version? I have a "Languages Support - Page Names  0.0.3" in my install; is that the one?

[Soma]

Yeah it's this LanguageSupportPageNames and is in dev with 0.0.6. Seems to exists in stable as with 0.0.3.

[ryan]

If you want to use the LanguageSupportPageNames module, I think it's better to go ahead and use the dev branch (if you are in a site development phase), just because (like Soma mentioned) the development for it is a lot further along there. 

[lloop]

When I have LanguageSupportPageNames and MarkupPagerNav installed together I get only the first set of results returned from a page array.

When I type the URL into the address bar with an added "page2" segment, the segment is removed also. The pagination works fine without LanguageSupportPageNames.

I tested in a clean install of PW. I'm using the dev version. Possibly I'm doing something silly? If not I would love to help fix this. I realize that LanguageSupportPageNames is in it's early stages.  Although I'm admittedly on the newbish side, I do like to jump into the deep end of the pool. As long as the adults are "keeping an eye out". Translate that to "please point me in the right direction".

[ryan]

Thanks for the report. I can confirm the issue and was able to duplicate it here. I should have it fixed later today on the dev branch and will try to remember to post back here once I do. 

[ryan]

Pagination is now fixed on the dev branch. Also you can now translate the the prefix segment (i.e. "page[n]") used for pagination in URLs. By default it is "page" for "page2", "page3", etc. But if you want to translate that on a per-language basis, you now can in the LanguageSupportPageNames module configuration screen. For instance, in Spanish you might want to make it "pagina" for "/path/to/page/pagina2", "/path/to/page/pagina3", etc. 

[lloop]

Now it works fine except for a page array on the home page in the default language, but not the secondary one.

In the clean install, clicking on the "page 2" link produces a URL with two slashes between the address and the last segment (the page 2 segment). Likewise, when it is typed into the address bar. I changed the "should URLS end with a slash?" setting, cleared caches, and tried different names for the languages on the home page (blank, or an entry like "en" and "de" for each). No change. Something to note is that , in the secondary language the two slashes appear but it doesn't seem to interfere with the pagination.

In my dev install when I click on the "page 2" link on the home page the URL becomes "page2" only . It removes the root URL. I have a feeling that might have something to do with my settings because I tweaked alot before I moved to the clean install in order to check this and have been using it since. Similarly, when I click the "page 2" link from within the secondary language, it works fine on this install also.

[ryan]

Just pushed a fix for this on the dev branch. Please let me know if you still run into any odd behavior with the page numbers off root. 

[ryan]

Not specific to multi-language page names, but since it's in the dev branch and related, I figured I'd mention it here…

Multi-language page fields inherit the default language value when they are blank. While probably a good default, sometimes this behavior is not desirable. So on the latest dev commit, you can now configure that behavior on a field-by-field basis (for any multi-language field). The screenshot below probably explains it best.

[dragan]

I've been reading docs and forum entries, but I am still scratching my bald head about this...

I have a multilang site with 4 languages, and the whole PW-setup is the "last URL segment" variety. (i.e. no subdomain. No entire, separate page-tree per language either).

There's about 4 areas where I need to create navigations: main nav at the top, another on the left, footer links + breadcrumbs.

If I switch from any language to the other, those navigation items don't respect the current language.

i.e. if I am on mysite.com/about/hello/fr/ (french)

I expected that all the various navigation items (links) would automagically produce also links for their french pages. But what it does, is just "fall back" to the default language URL.

Are there any "best practices" / tutorials that I have missed? What's the most clever way to show the user automatically a navigation in the current language? Sessions? 

(I am using both Soma's MarkupSimpleNavigation module and plain-jane PW API funcs, if that matters.)

[dragan]

Since English is not my native language, my question was perhaps not clear enough. I'll try and rephrase my question:

With a multilingual PW setup, is there a "standard" (in-built) way to tell PW "I want to create a link list, for the specific language the user has selected"?

These links, which I generate with standard PW API methods, should point the user to his / her language-specific pages, not the default language pages.

If the current user-language is known - let's say my last URL-segment is /fr - the user shouldn't get links to the default language links, but the links of his own language.

Sure, I can manually str_replace() URLs and construct links for each site-language, but that seems quite awkward. I try to figure out a way to handle this "the PW way", and I'd be glad for tips and pointers... After all, I guess I'm not the 1st guy building a multilang site with PW and facing the same problems?

[Soma]

A multilanguage setup can be done in so many ways I'm not sure what is yours. I'm not sure what's about language segment at the end of the url but it sounds cumbersome. There's plenty of info in the docs and forum. Most simple setup would be using LanguagePageNames. Youll have lang segments as the first segment and with this the language is automaticly set to user and thus to the system. You dont have to do anything a navigation will work without further addition like session or anything. There's some special functions available to get language urls explicit for example to generate language switch.

[dragan]

I am using example 1 setup from http://processwire.com/api/multi-language-support/multi-language-fields/#examples

No separate page-trees per language.

There is a URL segment, and if I switch from pagename/de/ to pagename/fr/, the content does show french language content. That is all working nice and dandy.

But the various scripts which generate links do not "recognize" in which language I am currently. 

I'd like PW to somehow recognize which types of links to render for me, based on the current user language. If I use a simple API call to get all parent x children and output $page->url - these links should point the user to the current language URL, not the default URL. PW doesn't add the necessary language URL-segment on its own. I don't know if it's supposed to do that, I'm just asking.

Is it necessary to add / inject something like

if($input->urlSegment1 == 'en') {

    // do this or that

}

 

to API calls? I already define such stuff at the very top of my header.inc for various purposes (and that is all working as it should). It's probably just one tiny thing I'm overseeing, and I'm sure similar stuff has been done many times before...

[Soma]

Using the approaches explained there are not recognized by PW itself, you'd have to take care of it somehow. There's everything explained on that page with examples.

I'm not sure many people have used this method yet and I think it's not the ideal solution for real multilang sites also because of the various things you have to take care. Consider all the cases and dealing with them like links in textareas etc. And you wont get speaking translated urls.

I only ever used separate tree and the LanguagePageNames, previously LanguageLocalizedUrl. It's a lot easier to deal with and setup plus the system works with it and takes care of urls etc.

Consider that those docs were written before there was corr language support as with LanguagePageNames shown in this thread.

[jacknails]

I am using example 1 setup from http://processwire.com/api/multi-language-support/multi-language-fields/#examples

No separate page-trees per language.

This is the way that works for me:

http://processwire.com/talk/topic/2979-multi-language-page-names-urls/page-3#entry33412

Then you can use Soma's Markup Simple Navigation module to generate your navigation, and it will just work.

[ryan]

Consider that those docs were written before there was corr language support as with LanguagePageNames shown in this thread.

Once 2.4 is ready and LanguageSupportPageNames is labeled as stable (it may be there already), I'm going to revisit the whole Multi-language documentation section, as LanguageSupportPageNames does change a lot with recommended approaches. 

I also just [last week] launched an update to http://www.tripsite.com that uses LanguageSupportPageNames, over thousands of pages and 5 languages. Previously it was using the multi-tree approach. It vastly simplified the underlying code of the site, and their editors are so much happier with this setup. The URLs are still mostly English (reflecting the previous names), but at least now it's up to them to decide what the URLs should be in each language. The PagePathHistory module is installed, so that whenever they change a page name, the old URLs will continue working. For instance:

English: http://www.tripsite.com/bike/tours/around-venice/

Dutch: http://www.tripsite.com/nl/fiets/tours/rondje-venetie/

Dutch (old URL): http://www.tripsite.com/nl/bike/tours/around-venice/

Now making multi-language sites is so much more fun... I just wish I had more projects that needed it like this one! Hopefully the next major upgrade to this site will be to go responsive. 

[diogo]

Ryan, speaking of responsive, you might want to increase the z-index of the social buttons (100 is enough), and make them position:fixed. As it is now when I close the browser window they go under the pictures and when I scroll horizontally they move away from the window side.

[ryan]

I've posted a new documentation section on how to use the multi-language page names / URLs in ProcessWire:

http://processwire.com/api/multi-language-support/multi-language-urls/

[ryan]

This is a reply to a PM from @dragan that is a continuation of his question above. I'm copying my response here just in case helpful to anyone else. 

FormBuilder is multi-language capable, at least the latest version is. Make sure you have the latest from the support board. It does need the $user->language set to the right language ahead of time. Even though FormBuilder is multi-language capable, some people still choose to just create separate forms per language, so that the resulting form submissions go into separate locations. If your needs are diverse, you may find creating separate forms per language is still a good idea. But give the multi-language form option a try just in case. The only thing to mention is that "select" fields are not (yet) translatable, so avoid using them unless for numbers, etc. You can still use Page reference fields to handle multi-language selects though (the same way you would in PW's admin). 

I'm not totally clear about what multi-language solution you are using, but your forum post mentioned example 1. That has since been removed from the old location since Multi-Language page names are now recommended for the previous examples. However, I'm keeping the old examples here now, in case you still want to reference it. 

Assuming you are structured similarly to example 1, adding the language URL segment to your URLs is something you have to do manually. It could also be done with a hook, but I would stick to doing it manually until you know everything works. 

ProcessWire 2.3.2 uses the new method documented here, rather than the one in example 1. But that documentation won't be applicable unless you abandon the method you were using (example 1). So if you've already invested a lot of time in pursuing example 1, then you may want to stick with it. Because it detects the language from the URL segment, you need to make sure that you have URL segments enabled for templates where you plan to use it (Setup > Templates > your template > URLs > URL segments). You need to code in your template files to detect the language. For example: 

if($input->urlSegment1 == 'de') $user->language = $languages->get('de'); 

That would need to be done first thing. You may prefer to put code like that in a common/shared include file, so that you only have to write the code once. 

When outputting URLs to other pages, you need to include that language segment as well:

foreach($page->children as $child) {
  $lang = '';
  if(!$user->language->isDefault()) $lang = $user->language->name; 
  echo "<li><a href='$child->url$lang'>$child->title</a></li>";
}

That way when someone clicks on a link, the language will be retained in the URL, i.e. /contact/de rather than just /contact/

Ultimately, this method is kind of a pain next to the multi-language page names method, which does all the work for you, and lets you actually have translated URLs. But unless it's a very big site, I think you'll find the example 1 method to work just fine, so long as you keep in mind that you have to manage: 1) setting the language; and 2) making your URLs include a language segment. 

[kixe]

I want to set $user->language to the default language of the browser at first opening of the site. How can I prevent that it doesn't switch back, after the user changed it, or the user-language is stored in the session?

[dragan]

Ryan,

Thanks again for your PMs and for writing a new multilang tutorial.

Sadly, using your language switcher doesn't work. If I am on a /fr/ page, it shows links to the default language URLs.

All language support modules, incl. the new Page Names module, are installed. I have an include file at the very top that defines languages, according to URL-segments.

When creating links as you described, simply with the API (appending $lang to $page->url) works nicely.

The MarkupSimpleNavigation module, however, doesn't do that on its own. That's probably because it was written before 2.3.2.

May I ask you how you generated navigations for Tripsite? i.e. did you use MarkupSimpleNavigation at all, or roll your own?

A few "real-world" examples would be nice.

[dragan]

When I try to create a simple breadcrumb:

$userLang = '';
if(!$user->language->isDefault()) $userLang = $user->language->name;

foreach($parents as $parent) {
	$url = $parent->url . $userLang;
	echo "<li><a href='$url'>{$parent->title}</a></li>\n";
}

The home-link (top parent) looks OK in the generated breadcrumbs, but I get redirected to an URL "fr/" - that's it. No domain whatsoever. I guess that's a bug, not a feature?

[ryan]

Dragan, it sounds like you are attempting to use LanguageSupportPageNames in combination with another multi-language solution (appending language segments to URLs). These cannot be used together. You either need to use the solution you started with, or abandon it and switch to LanguageSupportPageNames. If you are going to use the multi-language solution you started with, which was to append language segments to the end of the URLs, then you should definitely uninstall LanguageSupportPageNames. Or, if you are willing to remove all of your code that has to do with getting/setting $user->language, or modifying URLs, in your template files, then you can use LanguageSupportPageNames. The important thing to keep in mind is that LanguageSupportPageNames does all the work for you, so you do not need or want to have any code for dealing with languages in your template files (unless making something like a language switcher).