Symphony.

I’m trying to decide how best to set a session option for language with Symphony, as I’m not sure of the convention. Is there a way to append a language to the end of the base URL, before the rest of the URI string? So a URL of http://localhost/welsh/jobs would work?

Alternatively, how does Cookie Monster actually work? Do you just append a language option to the end of the URI to have it saved in a cookie, ie http://localhost/jobs/welsh?

I think when using Cookie or Session Monster extensions you can add the Event to a page and when that page is called, any URL querystring parameters become cookies/session values. For example:

localhost/jobs/?language=welsh

If the Jobs page had the Cookie/Session Monster event attached, you’d then set a language cookie/session language.

That makes sense, I’ll probably opt for that then methinks. So far Symphony has proved excellent for developing this multilingual site, it has saved me a lot of time. Still can’t speak a word of welsh though!

In fact Throlkim, maybe you can advise me on:

I will have a site with versions for each country

domain.com/uk , domain.com/de , ....

And per country any language of choice, for example

domain.com/uk/de

for a german living in england.

Now I wonder what would be best for locale and language selection:

• using a button and a cookie, invisible in URI
• using links, visible to URI

Consider that country and language are automatically guessed at first visit, also consider that special case should be taken into making clear to google that its not all duplicate content.

I like the URi visible way, since pages can then be bookmarked and emailed in lang and locale required. Yet in webshops for example I mostly see cookie-based setups…

I quite like the idea of having the language visible in the URI all the time, but I’d like it at the start, so http://domain.com/welsh/jobs/view/1 for example. I don’t think this is supported in Symphony at the moment as it would probably require different rewrite rules, so I’m going to opt for the cookie option due to time constraints.
It’d be an awesome feature for the future though!

You can have the language (or any url paramter) anywhere in the URI you like. Indeed unless you use the browser info (there is a language extension for that) you have to populate that first param, either you can have an event taht forwards the homepage to /welsh, or you let people choose their language and hit a link.

That last options is really simple, more then the cookie.

However if you wish to also rember the visitors choice, then you’d also have to use a cookie, but i’d say the visitor has to just change it’s browser settings…. (country reverse ip on th eother hand needs a cookie, to edit in case the reverse ip consistently thinks you are in another country)

I also would like to add to my considerations above;

In the case of bi-langual countries (belgium; french and dutch) or smaller countries part of bigger country, like wales. How do Welsh people google? I assume there is no welsh google, as for google its all just UK. So… when googling welsh search terms, if the welsh language is only visble by setting a cookie, google doesn’t see it…. so for SEO you must have linkable (uri visible) languages?…..

You can not have the language “anywhere in the URI you like”. If you want to have /de/jobs/ and /en/jobs/ you’ll have to create four pages: both /de/ and /en/ as well as jobs/ for each of them.

That’s due to the limitation that params come “after” the path, not “in front of it”.

Why not customise your .htaccess file to allow /de|en/ to be places before the rest of the path?

I guess it depends on the content/setup you want to achieve, but isn’t it only normal that you need to offer all these different pages (either static or served through testing the params)?
@Throlkim does the welsh param serve to display the entire site’s content in welsh, or does it just show all jobs with requirement of the welsh language?

I am not completely getting what the use would be of language params before the path, it would change the language but all the content would stay in english?

And still wonder about seo and cookie language settings; is this demo store dependant on a sitemap to have google spider all the languages, for example?

I’d be using it to display the whole site in welsh. My current language setup has a Languages section with a field for every bit of static text that’s now switched by the user (and it’s working perfectly, thanks to everyone’s help).
Now if I could append it to the start of the URI, as if the user was browsing a subfolder for their language it’d be great, and it’d no doubt improve SEO.

how does your url handles in the page look? something like

param1/param/language

@phoque Since I have been workign an a rather unconventional site (without sections and fields, transforming from flatxml files) I forgat; A regular setup for 2 languages would be: a section and 2 fields per language for the same output? In that scenario indeed the selecting of the language comes after the selection of the sections

So maybe an extension to change the htaccess file to indeed put the ISO country and language codes before the path would be perfect? Or even into the core of symphony: url param before and after the path when setting up a page?….

I’m currently using session-monster and URLs like http://domain.com/jobs/?language=english to switch the languages, where it’s kept in a session after that.
An extension to change the .htaccess rewrite sounds great, it’s a shame that my regex skills are pitiful!

You could consider a hybrid system (for seo) Use the extension to create sitemaps and have the links in those map have the language at the end:

http://domain.com/jobs/english

so that it’s spiderable

And for the visitors work as you do now, so keep the language hidden, once set with:

http://domain.com/jobs/?language=english

But… I believe (check mattcutts.com) seo has no problem at all with language at the end;

http://domain.com/jobs/english

Its simpler, transparant to the user, and he can bookmark it. So I would go that way, and not use the sessions.

I already gave up on completely translated url params too, when you do see them, it are just optional slugs for show, with a numerical id in front of them. Google doesnt matter about translated slugs, only people about slugs they can trust/understand.

Sure the htaccess file rewrite would be a nicety, but simply for the sake of visuals?… One could argue from a users point of view that if english params are used in multilang sites, it is most sensefull to add lang params as an option at the end, and not pretend to be browsing subfolders of a langugae folder, because the subfolders names are not translated, and that doesn’t make sense…

Symphony has limitations on where parameters can appear in the URL — they always appear after a page name. Therefore a Jobs page, you’d need to have:

/jobs/en/

If you want to put en first, before any pages you will need to two one of two things:

a) create a page named en and make this a parent page for all others. But you’d need to duplicate pages for each language (not good)

b) use a custom .htaccess rule to look for a two-character portion at the beginning of the URL and convert this to a URL parameter instead. Something like this might work, but I’ve not tested it:

RewriteRule ^(en|we)\/(.+)/?$ /index.php?language=$1&page=$2&%{QUERY_STRING} [L]

In layman’s terms this will look for a URL starting with /en/ or /we/, strip that out and load the page as though the language wasn’t there. Then it’ll add the language code to the page, so it should appear as a querystring parameter.

Note that this change is a customisation to a core file so when you upgrade to a new Symphony version you’ll need to remember to back this file up!

If your goal is to have an URL schema starting with the language name like http://localhost/welsh/jobs, you can achieve this by duplicating your pages and by sourcing out your entire XSL into utilities. Given your dealing with two content areas jobs and projects that need to be accessible in Welsh and English your page setup could be:

--- english
    |
    --- jobs
    |
    --- projects

--- welsh
    |
    --- jobs
    |
    --- projects

Symphony will automatically create 4 template files in /workspace/pages:

• english_jobs.xsl
• english_projects.xsl
• welsh_jobs.xsl
• welsh_projects.xsl

Change the source of both jobs templates, english_jobs.xsl and welsh_jobs.xsl, as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="../utilities/jobs.xsl" />

</xsl:stylesheet>

Do the same with both project templates:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="../utilities/projects.xsl" />

</xsl:stylesheet>

Now, you need to create two files in your utilities folder:

• jobs.xsl
• projects.xsl

Setup your layout in these two templates. You can use the $parent-path parameter to choose the current language given you follow Nick’s idea in the other thread:

<xsl:choose>
    <xsl:when test="$parent-path = '/english'">
        <xsl:variable name="labels" select="language/entry[language/@handle = 'english']" />
    </xsl:when>
    <xsl:when test="$parent-path = '/welsh'">
        <xsl:variable name="labels" select="language/entry[language/@handle = 'welsh']" />
    </xsl:when>
</xsl:choose>

The last step could be simplified using substring-after():

<xsl:variable name="labels" select="language/entry[language/@handle = substring-after($parent-path, '/')]" />

Inspired by this thread I created the Language Redirect extension

hi all! how are you guys handling toggling the main-navigation? klaftertief’s language redirect extension is really great! but it would be cool if there was an extension that duplicates the main-navigation for all countries that are listed under the preference for klaftertief’s language redirect extension, or maybe klaftertief could incorporate this into his extension.

maybe the navigation xml island could look like this:

   <navigation lang="de">
        <page handle="home" id="1">
            <name>View Greetings</name>
            <types>
                <type>index</type>
            </types>
        </page>
    </navigation>

this way it would be really easy to build a toggle function for the main-navigation

You can add a Page Type filter to your navigation datasource with something like {$url-language} or {$url-language}-{$url-region} as the filter value. Just make sure to tag your pages (set the Page Type) with the according language codes.

But you don’t need different pages for different languages. You can filter your entries by language parameter or output different fields of your entries depending on the language parameter. For a global language menu I posted a snippet in the extensions thread.

@klaftertief thanx for the tip and the help, but i have come to the conclusion that symphony is not the way to go for multilingual sites at the moment. as a nubie, it takes to much work to get a site up and running with navigation etc… i’ll use it for non-multilingual sites, but for now i’ll just stick with drupal.

once again thanx for all the help!