Symphony.

developers should make the field-name translatable.

I think this is a misunderstanding: developers should make the field names translatable (which are shown in the section editor when you select a field). This is about the custom labels that you setup after attaching a field to a section.

Symphony does not offer localisation support for user input at the moment.

If I understand correctly, @ixi wants to translate the label of a field in a section, which is not possible out-of-the-box. (So Nils is right.)

Translating the name of a field is possible, of course.

Hi Nils. You beat me!

Ahh, ok. Got it now.

Nils, this is a great idea for multilingual content... I set it up on one of my sections and noticed no WYSIWYG Your screen grab shows the same. How easy/hard would it be to have the WYSIWYG integrated in the future?

EDIT ignore me.. origianl section that I was linke to was using MARKDOWN. :)

So we've got our first potential multilingual site coming up and I've been reading through the forum looking at the current options.

One thing I can't see covered is the Select Box or Tag List. The Multilingual Field is basically a conversion of the Textbox, so that covers alot of the text requirements, but I couldn't see a solution to translate the Options of a Select Box for example.

I had a Subsection Tabs as well, and that doesn't seem to solve this situation either.

What are people using at the moment to achieve this?

Not quite sure what you're after, but at one point, we wanted to include a way to add a multilingual subnavigation in a site and simply used a Subsection Manager to enter word pairs.

It sounds like you are looking for a way to include filtered options (for a Select Box or Tags) though - a more general way to approach this would be to somehow alter the Subsection Tabs to pass out their names/languages so that other extensions could then react in specific ways, i.e. filtering.

@brendo

What are people using at the moment to achieve this?

I like the approach of Multilingual Field for texts. Perhaps it could be implemented to other fields as well, including Select Box.

I didn't need anything like this yet, but if I will ...

This is a nice thread to read about different approaches on multi-language sites!

I am now working on a project which will require at least four languages and it's quite enternaining trying to find the best solution.

I am using Page LHandles (with Language Redirect) to translate my page names, so that I don't have to duplicate pages or create custom data sources for the navigation.

In my case it's a community website so my goal is to translate the "framework" and not the content itself. The multilingual field would have been appropriate for the content.

But I need a "base" language for consistency's sake because there are plenty of categorization options, and the names of these options might sometimes change.

So, I decided on the following approach:

As an example take a classic list of categories, which require a name and a description.

I created a section with a single field called "handle" to hold all category names in my "base" language.

Then, created a second section with the columns:

• Handle - a select box link field to the source section with the categories;
• Language - a select box link field to a language section with just a list of supported languages, but even a simple text field would do;
• Name - a text field with the Category name in the selected language;
• Description - a text field with the category description in the relevant language.

And my data source is filtering by the language field on the $url-language parameter, provided by the Language Redirect extension. Thus, I only get the entries in the selected language.

For the static content I just call different templates.

Of course, I'm still working on this and I find improvements every day, but I guess I felt like sharing! (Hopefully, still being a Symphony rooky, I won't discover tomorrow that this approach is not implementable...)

@ellie

As an example take a classic list of categories, which require a name and a description.

I created a section with a single field called "handle" to hold all category names in my "base" language.

I was wondering ... why didn't you simply create the section for categories using the multilingual field for name and description? Then use the SBL to point to the entries.

For the static content I just call different templates.

What will you do when the HTML for this static content changes? Modify each template accordingly? I have a dilemma at this point myself ... Modifying 1, 2, 3 ... 20 templates every time HTML changes is a lot.

How are you all others dealing with bits of static content?

@vladG

I was wondering ... why didn't you simply create the section for categories using the multilingual field for name and description? Then use the SBL to point to the entries.

I just installed it to see what XML it's outputting and you are right, I could have used that. Hehe, do things the hard way, then discover and appreciate the beauty of simplicity...

EDIT: Actually, if I use the Multilingual Field I'm not sure how to output the name in the other languages. The handle - yes, but the value...?

For the static content I just call different templates.

I have two additional utilities: "master structure" and a "content page structure" (in the latter each page has its own template and the template's name is the same in all languages). These two utilities are the same for all languages.

Separately, I've got content-en.xsl, content-it.xsl etc to keep only my content. The templates inside of these are called from the "content page structure" utility. If I want to add a language, I only copy the content-xx.xsl file and translate it. And since the template names in the content files are always the same, I only have to decide which content file to include, without the need to change the names of the called templates.

@ellie

Actually, if I use the Multilingual Field I'm not sure how to output the name in the other languages. The handle - yes, but the value...?

Multilingual field returns the handles for all languages but the value only for the current language, provided by Language Redirect.

www.mysite.com/en => <name ... >Adventure</name>
www.mysite.com/it => <name ... >Avventura</name>

And thanks for the static part feedback.

Neat, thanks!

This is continuing from here.

@ellie

How do you define your variables to decide which XML to load? Its value is always different, based on the language...

Oops, my mistake. I updated my previous post as well.

PLH provides localized handles for each page, right? But it also preserves the Symphony Handle and Title for a Page and supplies a datasource with current page's parents. The files that I'm using are all named the same (/xml/en/events_title.xml, /xml/ro/events_title.xml etc) for a page called Title with parent set to Events.

So it's just a matter of concatenation.

<xsl:variable name="current_lang" select="/data/events/language-redirect/current-language/@handle" />

<xsl:variable name="current_page">
    <xsl:apply-templates select="/data/plh-page/page" mode="current_page" />
</xsl:variable>

<xsl:template match="page" mode="current_page">
    <xsl:value-of select="@handle" />
    <xsl:if test="page">
        <xsl:text>_</xsl:text>
        <xsl:apply-templates select="page" mode="current_page" />
    </xsl:if>
</xsl:template>

<xsl:variable name="__page" select="
    document(
        concat(
            /data/params/workspace,
            '/xml/',
            $current_lang,
            $current_page,
            '.xml'
        )
    )/data"
/>

So in variable $__page I would have workspace/xml/en/events_title.xml or workspace/xml/ro/events_title.xml, depending on the language.