Symphony.

Jens, after upgrading to the latest version, i'm stuck with this extension logic. Trying to open /en/page1 or /lang/pageN produces 404. What should i do? How should i tell the Symphony to open my pageN with $language param = lang ?

P.S. the URL Router extension helped me solve the task. Dear Author, you definitely should (oops, better must) broaden your manual page (for such noobs as I am :-) )

you definitely should (oops, better must) broaden your manual page

Yeah I know, already working on it.

Jens, I am a bit confused, too.

I thought that /en/page and /it/page should display the page, while a routing extension would serve to translate the handles, but I get a 404 for all /lang/page.

If this is the expected behaviour and I proceed with implementing routing I am not sure what logic I should follow. I'd think from /it/page to /it/pagina but if /it/page returns 404 then how would routing resolve it?

In case it's relevant, the same installation manages several domains. The 404 occurs on each of them, including the main one. If it didn't happen with the main domain I would think that this is causing some "interference", but it doesn't seem to make a difference...

Thanks a lot for any suggestions and for your work on "simplicity". I love the idea of using as much as possible the core functionalities.

PS. I have tried it with Symphony 2.3.3 and now with 2.3.4, both cases with version 2.0.

Edit - More info:

The main domain redirects automatically from www.example.com to www.example.com/en/ (always with 404), while no redirection occurs with the other domains.

Suggestion:

Maybe there is a point I'm missing, but it would be nice to be able to have the xsl templates not dependent on an extension. I don't see a big benefit of having the extension change field handles.

For example, instead of title[@lang = $language] we could have *[name(.) = concat('title-', $language)], where $language could be the value from the extension or a variable for whatever the site language is.

I thought that /en/page and /it/page should display the page, while a routing extension would serve to translate the handles, but I get a 404 for all /lang/page.

The idea is that (for example) you set up a single about-page in Symphony, and use the Routing extension to create different URLs pointing to the same page.

<route from="/:language/about/" to="/about/">
    <filter parameter=":language" match="[a-z]{2}" />
</route>

for URLs like /en/about/ and /it/about/, or

<route from="/en/about-us/" to="/about/" />
<route from="/it/chi-siamo/" to="/about/" />

for fully translated URLs like /en/about-us/ and /it/chi-siamo/.

In case it's relevant, the same installation manages several domains. The 404 occurs on each of them, including the main one. If it didn't happen with the main domain I would think that this is causing some "interference", but it doesn't seem to make a difference...

I'm currently working on a new Routing version that supports different routes for diferrent domains and subdomains, but in its current implementation (the one you're using), both the Routing and the Multilingual extension don't care about the domain and just look at the path, so it should work just fine in most cases.

Maybe the 404 is caused by one of your datasources or another extension?

Suggestion

Maybe there is a point I'm missing, but it would be nice to be able to have the xsl templates not dependent on an extension. I don't see a big benefit of having the extension change field handles.

For example, instead of title[@lang = $language] we could have *[name(.) = concat('title-', $language)], where $language could be the value from the extension or a variable for whatever the site language is.

That's actually pretty similar to how I did it in the beginning.

But the point is convenience and not cluttering up your templates.

You would also have to handle missing translations and fallback to the default language yourself in the template for every piece of content, which can quickly get really messy.

Actually, you don't need this extension at all to create a multilingual site with Symphony. You could just set up different pages and datasources for each language.

The motivation behind this extension was to get rid of some of this redundancy with minimal impact on the database structure and core functionality.

Hint

That said, if you still don't want the extension to mess with your datasource output, you can simply get rid of the dataSourcePostExecute delegate handler on line 33... ;)

On a side note

I'm currently removing multilingual support from a project where the client decided at a later point that it's no longer a priority and too much work to translate everything. The project already has lots of client generated content in the database.

It's still a lot of work (removing and renaming fields, changing routes, templates and datasources), but it's doable without losing content or fiddling with the database. Would be much more complicated if I used some of the multilingual field types, I guess.

Thanks a lot for the reply, Jens!

I still haven't installed the routing extension, I wanted to make sure this was the desired behavior with Multilingual first, which you confirmed, so this explains the 404!

The reasoning behind my suggestion is that clients change their minds afterwards so often... Even if a multilingual implementation would cost more in the future, they go with a non multilingual and after a couple of months I have to redo lots of fields and xslt to implement it. Or, as in your case, they decide they don't want it after it's been implemented.

I want to find a way to avoid the extra hassle. It's also becoming difficult for me to maintain websites that depend on multiple extensions for multilingual functionalities. I'm afraid to start updating old websites.

The motivation behind this extension was to get rid of some of this redundancy with minimal impact on the database structure and core functionality.

Indeed! I love the approach with adding the language code to the fields. I have decided to always use it, regardless of a client's request for multilingual.

For example, if the client wants the website only in Italian I will use fields like fieldname-it. If they want English at a later point, I'll only have to add the fieldname-en, and (but not required) change field labels and install the Parenthesis Tabs extension.

In my master.xsl I would have a variable that sets the default language, a variable that sets the actual language (in case the site is multilingual), and a variable I can use for the field names. Something like:

<xsl:variable name="lang-default" select="'en'" />
<xsl:variable name="lang">
    <xsl:choose>
        <xsl:when test="//params/language"><xsl:value-of select="//params/language" /></xsl:when>
        <xsl:otherwise><xsl:value-of select="$lang-default" /></xsl:otherwise>
    </xsl:choose>
</xsl:variable>
<xsl:variable name="lang-field">-<xsl:value-of select="$lang" /></xsl:variable>

So the field would be referred to as *[name(.) = concat('fieldname', $lang-field)], and I won't have to change lots of xslt - only the default language variable and the condition in the second variable in my master.xsl.

I don't think I want the fallback, as I don't see a need to mix up different languages on a page. But you are right that if it's needed it would get messy.

This approach might be redundant, I don't know. But I will try it with a few websites and we'll see.

Actually, you don't need this extension at all to create a multilingual site with Symphony. You could just set up different pages and datasources for each language.

I've thought about it... how to implement it without an extension, but I'm not sure it's worth the trouble. I certainly don't want to duplicate the pages.

Maybe I could manually add a rule in the .htaccess file, similar to the rules the Language Redirect extension adds (I so miss this extension!). It will give me a nice url-language parameter to work with right away.

But I would still have to write redirects to have translated URLs, and also the selected language won't be saved in a cookie. So a custom event might be needed if this is important.

So I guess, an extension is good to have for the routing.

I'm not sure if it's possible but it would be nice if the Routing extension could include the routes for all existing pages in the xml file (as per the moment of installation). Thus, one would only need to change what has to be changed (though, there might be a problem of overwriting the changes...).

As I mentioned, the project I am currently working on involves several domains managed by the same installation. However, only two of them need to be multilingual, so I only need routing for some of pages.

...both the Routing and the Multilingual extension don't care about the domain and just look at the path...

Does this mean that the extension looks at the paths after rewrite rules are applied by apache? I have some custom rules for the additional domains and I wouldn't want them removed.

Thanks again for your help, Jens! I will play around with the two extensions tomorrow and see if everything works.

(I apologize for the lenghty post...)

Jens, the extensions are great and so uninvasive. I like them a lot.

I have some issues that are caused by my multi domain implementation:

My main domain redirects automatically from www.example.com to wwww.example.com/en/. Can I prevent this because this domain is not multilingual?

Edit: I commented out the condition on line 116 and this fixed it.

Also, what routes should I use so that www.example.com/en/ wouldn't give me a 404? If I use <route from="/:language/" to="/homepage-domain1/"/> it would interfere with <route from="/:language/" to="/homepage-domain2/"/>.

I look forward to trying the new version of Routing. You've probably already thought about both of these issues.

That said, if you still don't want the extension to mess with your datasource output, you can simply get rid of the dataSourcePostExecute delegate handler on line 33... ;)

I tried but if I comment out the delegate I get:

MySQL Error (1048): Column 'delegate' cannot be null in query: INSERT INTO `sym_extensions_delegates` (`extension_id`, `page`, `delegate`, `callback`) VALUES ('24', '/frontend/', NULL, 'dataSourcePostExecute')

If I comment out the array it doesn't make a difference.

This hack would help me a lot as I won't have to change my xsl files.

Thank you again!

My main domain redirects automatically from www.example.com to wwww.example.com/en/. Can I prevent this because this domain is not multilingual?

Yes and no. It's currently not supported, but I ran into this myself in one of my current projects, so I'm already looking into it.

In the meantime, you can hack the extension and comment out or delete lines 114-119 (like you already did).

I tried but if I comment out the delegate I get...

I guess the extension is already subscribed to the delegate, so you need to uninstall it first, comment out the delegate handler and reinstall the extension.

Also, what routes should I use so that www.example.com/en/ wouldn't give me a 404? If I use it would interfere with .

Yeah, currently not supported, sorry.

I look forward to trying the new version of Routing. You've probably already thought about both of these issues.

Indeed.

I have not finished the new documentation yet, but if you drop me a line via email I can send you a pre-release version for testing.

Thanks! Uninstalling/Reinstalling did the trick.

Everything is working great now. Showing a 404 for www.example.com/en/ is not so big of an issue since there isn't an automatic redirect to it, only if the user types it manually. So, I'll leave it at that for now.

I would love to test the next version, email sent!

Thank you for this extension.

One request for a future version is an option for no fallback to the default language in case of optional fields in a section, like a subheading for example.

For now I commented out line 360-365.

Would this (mark fallback as fallback) work for your use case as well?

What do others think about fallbacks in general? Would people rather handle fallbacks in the template on their own and not have a fallback provided by the extension?

I prefer no fallback but set required fields for each language. In that way the user is more aware about the content.

Handle fallbacks in the template sounds as best of both worlds.

Jens, how do you handle with translations for the page names en page url handles?

The other multi-language method provides the Page LHandles extension.

I prefer no fallback but set required fields for each language. In that way the user is more aware about the content.

What about fields that would be optional in the first place, even if the site wasn't multilingual?

Handle fallbacks in the template sounds as best of both worlds.

Keep in mind though, when fallbacks are needed, you would have to handle the fallback via XSLT for every piece of content. While I like that it's the most simple and straight forward solution, it would also lead to a lot of template code for a really simple task. Not sure about this.

Jens, how do you handle with translations for the page names en page url handles?

See comment #24 above.

For the page names, you could set up a helper section where you store multilingual data for each page like title, metadescription, etc.

You can relate these entries to pages in different ways, for example via the page id, the original title or the Pages Field.

I've got a strange behaviour with two url params (/cat/title).

Main language english:

en/products/our-products/the-product

Second language (dutch) but the title has no translation (the expectation is that there will be the fallback to the main language), but

nl/producten/onze-producten/the-product, returns an empty result (404)

if the cat parameter is in the main language it works as expected.

nl/producten/our-products/the-product

The category is provided by a select box link, so I thought it was the same issue as this. But if the title has a translation it works as expected

nl/producten/onze-producten/het-product

I thought I solved it by using an output parameter from the category data source and use the output parameter for filtering the pages by category.

For the category it works perfectly but sadly enough now it returns on the title in the second language an empty result (404)

Second language (dutch) but the title has no translation (the expectation is that there will be the fallback to the main language)

Yes, if there's no translation it should work with the default (fallback) language as well.

I thought I solved it by using an output parameter from the category data source and use the output parameter for filtering the pages by category.

That explains a lot. It won't work when comparing the value of the select box link directly with the cat-parameter. You need a separate datasource and chain them together via output parameters (system id).

Thanks Jens. Chain the data sources on system id for the select box link is the solution.

Hi jensscherbl, and all symphony users. I have download extension but I have problem. I am trying to install extension but in admin system-extensions I can't find it. I place multilingual-master folder in extensions but in admin it just doesn't showing. I am using symphony 2.3.4 version.

@justalec: github-zip-downloads always change the name of the root-folder. Rename it to multilingual instead of multilingual-master and the extension should be found.

Ok, thanks @Roman.