Search

A new extension, "Frontend Localisation" 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.

Make sure you see the Readme. It's all there.

It provides the tools to add other storage formats like GNU PO and JAVA properties, for example. At the moment I don't have the time to add them, but if there's a brave guy out there to help with it ... :)

Frontend Localisation updated to version 1.3 on 9th of January 2012

  • Fixed some bugs regarding Page's Translation management on saving a Page.
  • Fixed a bug where the handle of a Translation item wasn't changing on saving through UI.
  • Fixed a bug where the relation between Translation and Pages wasn't removed on Translation deletion.

At the moment, the UI allows only changing of Items handles. If you like this extension and want to make it better, you can help with creating the "Add new item" & "Delete item" features.

Github repo

The primary goal at the moment is to finish the UI so not even the developer should need to edit files manually to add/delete Translation items. Everything should be done through the UI ( lazy dog :) ).

If you find other bugs, please report them on the issue tracker.

@todo list:

  • add support for GNU PO and JAVA properties.
  • implement Add new item | Delete item | Item reordering (subgrouping) features (need help with the JS here).

I get the following error when entering "Translations" Fatal error: Call to a member function getTranslations() on a non-object in /www/siteroot/extensions/frontend_localisation/content/content.index.php on line 56

and also when creating a new page: Fatal error: Call to a member function getTranslations() on a non-object in /www/siteroot/extensions/frontend_localisation/content/content.index.php on line 222

any idea? Language driver is set To Language Redirect v1.0.3

Ok, seems this only occurs if entry_url extension is installed

Multilingual Entry URL ftw :)

Ok, seems this only occurs if entry_url extension is installed

Odd. I can't reproduce this. I just activated Entry URL and I was able to navigate to "Translations".

Is your Symphony install a fresh one? Do you have any Pages created?

I would like to fix this. If you are kind, could you post the stack trace?

It was a fresh symphony 2.2.5 installation with no pages created at this time, so also no translations.

Just added some bonus to FL : Utilities templates.

It now supports params replacement, just like __(...) in PHP.

Translation file:

        <data>
            <p_news>
                <item handle="view-all"><![CDATA[View %1$s or head back to %2$s.]]></item>
                <item handle="news-link"><![CDATA[all news]]></item>
                <item handle="home-link"><![CDATA[our spify home page]]></item>
            </p_news>
        </data>

Call template:

        <xsl:call-template name="fl__">
            <xsl:with-param name="context" select="'p_news/view-all'"/>
            <xsl:with-param name="reps">
                <rep loc="%1$s"><xsl:value-of select="fl:__('p_news/news-link')"/></rep>
                <rep><xsl:value-of select="fl:__('p_news/home-link')"/></rep>
            </xsl:with-param>
        </xsl:call-template>


If your are slick, you can pass HTML code as well:

        <xsl:call-template name="fl__">
            <xsl:with-param name="context" select="'p_news/view-all'"/>
            <xsl:with-param name="reps">
                <rep>
                    <a href="http://www.xanderadvertising.com" title="Xander Advertising">
                        <span style="color:red">
                            <xsl:value-of select="fl:__('p_news/news-link')"/>
                        </span>
                    </a>
                </rep>
                <rep>
                    <a href="{/data/params/root}">
                        <xsl:value-of select="fl:__('p_news/home-link')"/>
                    </a>
                </rep>
            </xsl:with-param>
        </xsl:call-template>

See the utility for more details.

Just added some bonus to FL : Utilities templates.

It now supports params replacement, just like __(...) in PHP.

Translation file:

        <data>
            <p_news>
                <item handle="view-all"><![CDATA[View %1$s or head back to %2$s.]]></item>
                <item handle="news-link"><![CDATA[all news]]></item>
                <item handle="home-link"><![CDATA[our spify home page]]></item>
            </p_news>
        </data>

Call template:

        <xsl:call-template name="fl__">
            <xsl:with-param name="context" select="'p_news/view-all'"/>
            <xsl:with-param name="reps">
                <rep loc="%1$s"><xsl:value-of select="fl:__('p_news/news-link')"/></rep>
                <rep><xsl:value-of select="fl:__('p_news/home-link')"/></rep>
            </xsl:with-param>
        </xsl:call-template>


If your are slick, you can pass HTML code as well:

        <xsl:call-template name="fl__">
            <xsl:with-param name="context" select="'p_news/view-all'"/>
            <xsl:with-param name="reps">
                <rep>
                    <a href="http://www.xanderadvertising.com" title="Xander Advertising">
                        <span style="color:red">
                            <xsl:value-of select="fl:__('p_news/news-link')"/>
                        </span>
                    </a>
                </rep>
                <rep>
                    <a href="{/data/params/root}">
                        <xsl:value-of select="fl:__('p_news/home-link')"/>
                    </a>
                </rep>
            </xsl:with-param>
        </xsl:call-template>

See the utility for more details.

Hi, I'm trying to build a bilingual site. After a bunch of time spent relearning Symphony and trying to figure out the best way to implement multilingual support, it seems a combination of FL and multilingual_field is the best solution (subsection manager's tabs unfortunately being broken for 2.30). So thank you very much for your extensions! They're very helpful, and they've definitely saved me months and made this project possible in the first place.

Anyway, I was wondering if there's a way to remember the user's preference for a language. For example, I'm trying to build a site where en is the primary language and fr is a secondary one. Currently when a user omits the language code from the url, e.g. when visiting {$root}/about/, en is automatically selected. If a user clicks on the "Français" link to go to {$root}/fr/about/, and from there clicks another link to go to /entry/blahblah/, they will be back to english. Ideally I would like Symphony to remember that the user last visited something in french and automatically redirect from /entry/blahblah/ to /fr/entry/blahblah/ — effectively acting as though the primary language were fr.

I know an easy fix would be to just change the link to /fr/entry/blahblah/, but I'm trying to make the backend foolproof for the authors so that when they write links they can omit the language code without having to worry about localization.

Is this functionality already available in some way? It seems to be a reasonable feature, and I'm sure other people have needed it already at some point. I don't fully understand these extensions yet so I'm not sure if I missed something.

If not, what would be the best way to implement this? Cookies? (I'm not even sure how to make cookies anymore since events have changed so much. Also, it seems that I would have to attach an event to every page in this case, am I right?) Hacking a patch into the extension? Making a new extension?

Hi,

In my opinion your aproach has some problems.

  1. Google and other search engines will never be able to 'set' a language so this would mean that they will always browse your site in english and your content in other languages will never appear in search engines.

  2. Your authors would still have to write links in multiple languages. There are ways and templates where you could ask them to use an ID of the page and then you generate the url. This way you always have the right url for every language.

  3. The alternative would be to use sub-domains or multiple domains. You write your code in the same way, then modify your .htaccess and redirect fr.yoursite.com to set the url parameter.

  4. I think the request was more related to List itemLanguage RedirectList item then Frontend Localization.

I think I should write a small how-to about building multilingual sites with Symphony :)

@River

I'm trying to build a site where en is the primary language and fr is a secondary one. Currently when a user omits the language code from the url, e.g. when visiting {$root}/about/, en is automatically selected. If a user clicks on the "Français" link to go to {$root}/fr/about/, and from there clicks another link to go to /entry/blahblah/, they will be back to english. Ideally I would like Symphony to remember that the user last visited something in french and automatically redirect from /entry/blahblah/ to /fr/entry/blahblah/ — effectively acting as though the primary language were fr.

I think you missed Page LHandles extension in your setup. It allows the localisation of your Pages titles & handles. It also provides a very useful utility which helps you to build the localised URLs. Using it, after clicking on Francais link, all generated links will be in French.

Anyway, I was wondering if there's a way to remember the user's preference for a language.

Like when a user visited the site in french, then comes back and French should be the default language for him? As @gunglien mentioned, Language Redirect has this option. It needs some update though to integrate it nicely with this workflow.

@gunglien

then modify your .htaccess and redirect fr.yoursite.com to set the url parameter.

How would I do that? I'm totally parallel with .htaccess stuff.

Hi, thank you both so much for your help and for taking the time to respond!

Google and other search engines will never be able to 'set' a language so this would mean that they will always browse your site in english and your content in other languages will never appear in search engines.

gunglien, you raise a good point but at the moment I'm not very concerned about search engines indexing the French content — I'd be happy just to get everything working at this point. As for your second point, it's just occurred to me that I could probably manage to pull off some XSLT to process all the author-created links and add language codes as necessary. Or I could try my hand at using PHP to process all links from textbox fields after the text is processed by markdown and have the entries in the database use links with appropriate language codes in the first place.

I think the request was more related to List itemLanguage RedirectList item then Frontend Localization.

I didn't know about Language Redirect because I filtered only 2.3-compatible extensions but it seems to be exactly what I was describing — an event attached to every page that stores a user's language preference in a cookie and redirects to the appropriate localization based on language preference. Thanks for the link! I'll definitely look into how klaftertief did it and try to hack together a solution from that.


vladG, I was actually also thinking of writing a small tutorial once I finish building this project to spare others the trouble I went through of sorting this stuff out. Let me know if you need any help. :)

And thank you for the link to Page LHandles! I was actually playing around with it but I could never get it to work so I gave up. I followed the readme on a fresh 2.3 install and even after attaching the DS to all of my pages and clicking on "Fill test Names and Handles for Pages", it behaves as though the extension weren't installed. Going to /home/, /en/home/, and /fr/home/ works, but /fr/frhome/ (and any other combination I could think of) gives me the 404 page. Also, the /data/navigation in the XML is the same as before and doesn't have the <item lang="_CurrentLanguageHere_" handle="_LocalisedHandleHere_">_LocalisedTitleHere_</item> mentioned in the readme. I've no idea what I did wrong. :S

(This probably isn't even the right place to post it, so sorry about that. I didn't want to make this an issue on github because I'm not sure if I'm using the extension right.)

@vladG its quite easy actually. Language redirect if I am not mistaken adds a very basic .htaccess rule that reads the following.

### LANGUAGE REDIRECT RULES start
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(en|ru)-?()?/(.*/?)$ index.php?language=$1&region=$2&symphony-page=$3&%{QUERY_STRING} [L]
### LANGUAGE REDIRECT RULES end

What you do is the following. Set all your sub-domains (fr/de) etc to point to your 'main' directory anyway. But add the language parameter for each subdomain in the .htaccess

RewriteCond %{HTTP_HOST} fr.domain.com$ [NC]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*/?)$ index.php?language=fr&symphony-page=$1&%{QUERY_STRING} [L]

The .htaccess rule might not be perfect as I don't have the live example here to check but should be something along those lines. I actually use a different domain for one company. So it would be like domain.fr / domain.com / domain.de / domain.it

The concept stays the same you just change the http-host rule for each domain that you have.

@River I'd also be interesting in writing how to set-up a multilingual setup. Though to be honest I don't really fancy using Front-End Localization in my setup too much of an overkill to update translations. Somewhere in my plans I also have the idea to release a multilingual ensemble... All I need is to find some time.

.htaccess kept throwing headaches at me. The first headache was admittedly my own stupidity, since I couldn't make ?debug work, forgetting that although I was logged into Symphony backend on domain.com, I wasn't logged in anymore on fr.domain.com.

Anyway, I managed to get the subdomain redirection you suggested, gunglien, working on my local MAMP install, so I thought I'd share what I have. The following replaces the original FL stuff in .htaccess.

RewriteCond %{HTTP_HOST} ^fr\.(.*)$ [NC]
RewriteRule ^(index\.(php|html))?$ index.php?fl-language=fr&symphony-page=home&%{QUERY_STRING} [L]
RewriteCond %{HTTP_HOST} ^fr\.(.*)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*\/?)$ index.php?fl-language=fr&symphony-page=$1&%{QUERY_STRING}    [L]

The two RewriteRules is because for some reason the !-d and !-f prevent redirection from fr.domain.com/ (the homepage); however, getting rid of !-d and !-f will result in a redirect loop for every other page. I tried another solution where everything from fr.domain.com will redirect to domain.com/?fl-lang=fr&symphony-page=$1&… but the URLs got very messy. I also replaced domain.com with (.*), which seems to work just as well.

If anyone can think of a better way of doing this, please let me know. :)

Frontend Localisation updated to version 1.7 on 26th of June 2012

There's a new delegate in Translations Datasource (/data-sources/data.fl_translations.php) called FLdsTranslationsPreRun. What can you do with it?

  • Create an extension that listens to this delegate and includes various Translations for emails sent with ETM.
  • Dynamically change the source of translations in your workspace folder (or any folder) based on a theme system that you created.

@vladG and all familiar with multi lingual symphony, just anxious to read a tutorial about this theme.

the tutorial could point the extensions combinations and different methods to develop, for example:

  • language directories and localized urls: website.com/en/about -> website.com/pt/sobre
  • language domains: www.website.com (english), br.website.com (brazilian portuguese)

could you point the basic steps?

No so sure if there's a complete tutorial about a multilingual setup.

I think the current Frontend Language extension will not by itself cover both of those scenarios; you would be required to do some .htaccess redirects or otherwise. basically removing the lang parameter and passing it as a query string fl-language (there is also a regional param which you can use). Then I usually use multilingual text box for all my text; page lhandles to handle the url handles in multiple languages.

I know tat Frontend Language offers a translation feature however I tend to prefer creating my own section with keys / translations in symphony and manage it through the db.

Hi,

I have a problem in the backend with this extension.

This is the context:

Three languages: ca,es,en Default and reference language: Catalan (ca)

Section fields: - Multilingual Text Box (single-line) for Title - …

The problem is that on the entries table of the section, only 'english' is shown for the Title, so if there's is no english translation for it, the Title is left blank, and thus not clickable.

I'm expecting these titles to show on the the default language…

I assume this happens because the entries table fetches the values in Symphony's Core language (in this case english) but I'm not sure.

What can I do?

[I don't mind translating the core to catalan, I'd need a little guidance with creating the extension though if possible]

Thanks a lot in advance.

Attachments:
Captura de pantalla 2012-09-17 a les 12.15.56.png and Captura de pantalla 2012-09-17 a les 12.15.12.png

cstll_a this is a problem with the TextBox extension - I've fixed this and i'm waiting for it to be pulled into the main repo. meanwhile you can try changing your textbox field to the following repository https://github.com/jonmifsud/textboxfield (if using zips just download and replace) should fix your click problem.

As for the translation (complete) I've never done that myself but there are other extensions that you can use as example. Usually I prefer to install all the languages and then match them up with Backend Language Switcher. so all your fields will appear in the right language from the backend.

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