Symphony.

Hi,

how I can translate the Section Names and Page Titles ?

Is that possible ?

THX

Check the multilingual field and the language redirect extension. They will permit you to do it, and will even provide the good values without changing your xsl.

http://getsymphony.com/download/extensions/view/41994/ -- Language redirect http://getsymphony.com/download/extensions/view/46066/ -- ML field

you can even check the PL handles http://getsymphony.com/download/extensions/view/61886/

I use those three extensions a lot !

But.. those aren't multi-lingual section titles

I created "Dictionary" section, where we store all translatable "static" text. Data-source selects whole XML (dictionary data is edited as normal text in textarea, and formatted to XML, so it is a single entry containing all translations) by language code. Later XSLT uses simple template to translate text. It is very similar to how gettext works, so it falls back to "default" language (English in our case):

<xsl:template name="dictionary">
    <xsl:param name="src" select="''"/>
    <xsl:variable name="dst" select="/data/dictionaries/entry/dictionary[@mode='formatted']/p[@id=$src]"/>
    <xsl:choose>
        <xsl:when test="$dst!=''">
            <xsl:value-of select="$dst"/>
        </xsl:when>
        <xsl:otherwise>
            <xsl:value-of select="$src"/>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

And then call it from other templates this way:

<xsl:call-template name="dictionary">
    <xsl:with-param name="src" select="'English text to translate'"/>
</xsl:call-template>

In place of 'English text to translate' there can be variable, or section/page name taken from other data-source (you can use Section Schemas extension, or other solutions).

@awayakchih

Great idea with the dictionary section.

@into: Not section names, but page title yes !

@ahwayakchih: I normally create a utility that has plenty of templates and variable containing all "static" translations. This prevents my clients to edit it, which, in most cases, is essential.

But the Dictionary section is not bad at all :)

vladG, thanks :).

Nitriques, whole point in Dictionary is to allow client to edit it easy way, you can always block section edit for Authors (so only Developers will be able to edit it). Otherwise i would probably store translations in XSLT (or some XML as static data-source).

@ahwayakchih: Thanks for the tip!

@ahwayakchih: How should I block access to it ? With the Author Roles Ext ?

Nitriques, i did not try that extension, but it looks like it may work. Or you can make that section hidden - Developers will be able to get to it through blueprints/sections :). If you want to make sure that no author will try tricks to change data, write simple extension that checks if author is developer or not and outputs 403 error (or redirects to some other page) when needed - similar way to the one you used in your Anti Brute Force extension :).

@ahwayakchih: never tried it neither (authors roles), and if it does not work, it should be pretty easy to implement :) Thank you !

BTW, did you update to the latest version of ABF ? They are some pretty neat features, I hope you like it!

Right... I just started a different discussion on resource localization only to realize now that this thread is about the same subject.

For one of my projects I came up with the same dictionairy approach as ahwayakchih, but there is a catch to this: it is very difficult to sustain this in a DTAP deployment scheme.

Most of the static text resources are conceived during development. When you want to go live with this, you will need to make sure that you have tracked all changes and recreate them on the production environment. It is not a simple copy / paste job. Especially not if you allow your clients to add translations.

So I've found this approach to be cumbersome and was hoping that there would be a cleaner solution, like the nifty multilingual support in the Symphony backend / extensions.

Nitriques, i did not try it yet, but i will. I saw new features and they seem like a good thing :).

remie, i did not try this but maybe it could work: on development version, create dynamic_xml data source, that "downloads" translations from production site (where you setup special page which simply outputs translation XML). That way you will have up-to-date translations (that clients can update whenever they want) and you will not have to setup mirrors/mergers/etc... Symphony backend translations have the same problem, it is just that they are not easly editable by clients through administration pages (but they still can modify translation file, so it is better to check it before uploading developed changes).

@ahwayakchih: Good: Post issues in their repros if you find any, I will try to install it too.