Search

A new extension, “Multilanguage Support” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Multilanguage support for Symphony 2.0.7 and 2.1

This Symphony extension adds a multilanguage support layer on top of Symphony 2.0.7 and/or 2.1.

Important: This extension is still in beta. Now it supports multilanguage support for input-fields and textarea’s, but dropdowns, multi-selectboxes and rich text editors are currently not (yet) supported.

How it works:

On the backend

In preferences, you now can add multiple language codes which will become available through the site (like ‘en’, ‘de’, ‘nl’, etc…) When you create a section, each field now has an extra parameter called ‘Multilanguage’, making the field multilingual. Now, when you create an entry, you’ll note that there are extra tabs on top of the page, each representing it’s own language. Also, a new datasource is available in ‘Components’, called ‘available languages’, which represents the different languages as supplied in preferences.

On the frontend

The first parameter of the url will be the language code (for example: http://mysite.com/en/my-page). This parameter is added to the parameter pool called $url-language-code. This represents the code of the current language shown. If no language code is provided in the URL, by default the first language as given in preferences is chosen. According to the chosen language, the right content is automaticly placed in your datasource, so there is no need for filtering languages in your XSL templates.

Important notes

  • This extension modifies the .htaccess file, a backup is made, but if you use other extensions which also modify the .htaccess file, errors might appear.
  • This extension is still in beta. Now it supports multilanguage support for input-fields and textarea’s, but dropdowns, multi-selectboxes and rich text editors are currently not (yet) supported.

This seems like an extension duplicating the functionality provided by the Language Redirect and Multilingual Field extensions? The Multilingual Field extension also already works with text formatters.

I’m just thinking it would be more appropriate to combine all efforts towards good multilingual solutions. guillem_l is the developer of the two extensions mentioned above.

Although they might look the same they are not. Where guillem_l’s extension adds a new type of field, this extension attempts to make all fields multilingual. This gives the option to create multilingual checkboxes, file uploads, dropdowns, tag lists, etc… all multilingual.

Because you might want to disable some things in certain languages (checkbox), or have different images or PDF downloads in other languages (file uploads), or different tags or banners (tag list, multi select box), etc…

Although the current release is beta, this extension will aim on providing a global multilingual layer on top of Symphony by using it’s existing fields (and in an ideal-situtation also the field-types provided by other extensions).

Does your extension provides URL translation?

The only way I found to do this was to duplicate each page, once for each language :-/

Not sure what you mean bpierre, but have you looked at the Language Redirect extension I mentioned above? It basically adds a “current language” parameter which can be used to filter content.

The “Multilingual Field” extension is based on this to provide language specific content, I would assume this “Multilanguage Support” extension also takes this into account.

@bpierre

I have yet to find a CMS that offers URL translation. Considering the seo advantage is only the increase of likelyness of people to click on a google result, because the url makes sense, is readable, I figure that english urls across all languages would be ‘good enough’.

It would possibly actually be an SEO dis-advantage as Google can translate pages, so if your URL is the same but in a different language, it may read the content as appearing twice, which loses page ranks. The best method is to append a URL level that is the language (as described above). Well, in my opinion…

has this been said by matt cutts or is it proven somewhere?

I didn’t know who Matt Cutts was until you said! lol

I did say in my opinion, I should have been more indicative of that… I shall try to find out, which could be difficult…

Multilanguage Support updated to version 0.3b on 11th of August 2010

Update: since v0.3b CKEditor is supported as rich text editor

@newnomad: I do know that Google actively recommends presenting content in different languages with different URLs: Google Webmaster Tools Help

I’ve installed the extention and added 2 languages (en,nl) in the preferences. Then i checked the boxes (multilanguage) in the section manager. The tabs EN and NL showed up in in the entry manager. So far so good….

But when i hit the “save changes” button at the bottom, nothing happens! Even no error shows up..

Im using Symphony version 2.1.1 with the default symphony template (in mozilla firefox)

I tried to do it in a different browser to create a new section and entry to re-download and re-install the extention

Nothing worked…

(this is the only non-core extention i’ve installed at the moment)

Does anyone have a solution for this??

@ froded

Yes, but the slug on their example is exactly the same language, only the path preceding it is different, correct?

@newnomad: Yes, but it’s still a different URL. That’s the main thing: Different content (language) with different URLs. Then you can get even more benefits from completely localized URLs for localized content, since Google will match language specific search terms to the URL as well.

If you have a page about… polar bears, and the page contains the words “polar bears”. Then you’d probably get better search result placement when searched for if your URL contains “polar” and “bears” as well. If this content exists in multiple languages, translating the URL will also help for each different version (eg. “isbjørn” in norwegian).

I have read on the site of Matt Cutts (and got it conformed on a django forum once) that google does not spider urls paths for content, but he acknowledged that well readible, possible translated, slugs are good to convince people to clik trhough on their search results, becasue they are displayed, and so there is more trust that the link wil go to what they are looking for.

So we need to check our facts to be 100% sure…

I can’t say with 100% certainty that Google indexes keywords in the URLs, but:

  1. “The URL http://www.example.com/green-dress.html is much more useful to us than http://www.example.com/greendress.html. We recommend that you use hyphens (-) instead of underscores (_) in your URLs.” - URL Structure, Google Webmaster Tools Help
  2. “If your URL contains relevant words, this provides users and search engines with more information about the page than an ID or oddly named parameter would.” - Google Search Engine Optimization Starter Guide, page 8

You’ve probably seen yourself that Google highlights your search terms if they’re found in the URL as well. So to me, having language specific keywords in the URL does help users find your site when searching. Even if it’s just because they recognize the keywords in the URL, which Google also highlights.

To me it makes sense to use different URLs for each language version, marking up the HTML with the language of the content (eg. <html lang=”en”>) and ideally using language specific keywords for the URL, matching page titles or other content.

Seems like this thread went wrong way…

Is there any solution or comment on issue mentioned in Comment #13? I have exactly the same problem.

Have you tried adding

php_value display_errors on

in your .htaccess to display errors or maybe the logs in /manifest/logs/ show what’s going on.

file in manifest/logs is empty (except header), without errors.

I’ve also try display_errors in .htaccess, but I’m not getting any errors…

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details