Symphony.

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

gettext

Description

Ahhh yes... yet another extension in the battle for Multi-Language support! This one is more developer centric: it allows you to translate those small words like "Login", "Username" and other small pieces of text that needs translation but aren't exactly what you would call articles.

Requirements

This extension requires Symphony 2.2.x and the Language Redirect extension.

Installation

1. Download and install the Language Redirect extension
2. Download the Language Parameters extension and add it to your extensions folder using languageparameters as the folder name
3. Add an XML file in the Manifest folder called staticresources.xml
4. Add parameters to your XML file (look at the Usage section below for more information)

Usage

The extension uses a simple XML file in the manifest folder called staticresources.xml. The schema for this file is:

<resources>
    <language code="">
        <param name="" value="" />
    </language>
</resources>

For large amounts of text (don't know if this is the right extension for it, but it is supported), you can create childNodes for the @name and @value attributes:

<resources>
    <language code="">
        <param>
            <name></name>
            <value></value>
        </param>
    </language>
</resources>

You can combine this, by using the @name attribute, and the value childnode, etc, etc. Keep in mind that it will first use the attribute value, and if the attribute does not exist, it will look for the node. If there is no attribute and no childnode specified, the extension will throw an error.

Each parameter is added to your frontend as... XSLT parameters! So you can get the value in your template by using $name (which happens to be the value of the @name attribute in your staticresources.xml file).

Caveats

Language Redirect based

In order to get the parameters for a specific languag code, the extension matches the @code attribtue value with the value returned by the LanguageCode property that is returned by the Language Redirect extension.

So if this returns 'en-us', based on the provided URL http://example.org/en-us/somepage, the extension will look for the following xpath in the staticresources.xml file: /resources/language[@code='en-us']/param.

Default language

If there is no language specified, the extension will look for the default language code as specified in the Language Redirect preferences. If there is no default, no parameters will be resolved.

If the extension does not find parameters based on the language code returned by the Language Redirect extension, it will not resolve any parameters.

Missing Parameters

Keep in mind that missing parameters might cause your Symphony instance to throw XSLT errors! To avoid this, you can either make sure your staticresources.xml file is up-to-date, or add

<xsl:param name="name" />

to the top of your XSLT pages, to ensure that the parameter is declared.

Roadmap and Version History

Can be found on the GitHub repository: https://github.com/remie/StaticResources/issues

Language Parameters updated to version 1.1.0 on 6th of September 2011 Renamed extension from static resources to Language Parameters

Good move with naming.. I thought original name had something to do with static sections when first read post title. great idea for extension. thanks for sharing.

Thanks... I'm still not satisfied with the name, for now it seems like this will add parameters with language information. I'm have trouble coming up with the right description :)

Remie, if I understand you correctly this adds support for sort of a 'gettext' internationalization, correct?

I have need of something like this soon and have been thinking about how to handle i18n strings throughout my template.

I'm sure you've given it some thought but it would be great to be able to define/manage these string in the Symphony backend.

Also, would it be very complex to decouple this extension from the Language Redirect extension? If I understand correctlty that extension is only needed for retreiving a language param. I currently have no need for language redirection and have another way of setting a $language param so it would be neat if I could 'feed' my param to your extension directly…

Thanks!

PS: I've noticed your Roadmap link still links to the old StaticResources (404). Link should be: https://github.com/remie/LanguageParameters/issues ;)

Translated Labels

?

@David: Yeah, it's indeed basically a version of gettext, hadn't looked at it like that though :D The point was that I was messing around with sections with multi-language fields for just simple strings and which became a real hassle to maintain. Next I tried using the Global Parameter Loader extension, but this was not working and didn't have multi-language support. So I came up with this.

There have been several thoughts going through my head regarding this extension :) But I needed a basic version asap, which resulted in the current version.

I've been thinking about three things:

1. Add some sort of properties files, comparable with the current multi-language implementation used for the Symphony backend / extensions and JAVA i18n implementation.
2. Bring the management of strings to the Symphony backend (see issue #3)
3. Deal with language selection. I didn't like the coupling with Languag Redirect as well, but it was the easiest way to implement it for now :)

If you have any idea's about how to implement the above features, let me know!

P.S.: I cannot edit the post anymore, so I cannot change the URL :(

@nickdunn "Translated Labels" indeed describes this extension better IMO.

@remie This extension is a great start and something I'd imaging that a lot of people would use. I think starting simple is often best.

Re: your points (from a layman's POV):

1. I'm not sure I understand.
2. Yes. I think this should not be too difficult. We're basically talking about a simple Labels section outputting a XML Page based on a DS that filters on a $language param.
3. Could this not be done in a very 'naive' way? Simply by expecting a global $language param. It does not matter how it is exposed as long as a $language param is present, no?

@david

1. It is common practice in JAVA and the Symphony extensions to add language specific labels in separate files (lang.nl.php, or labels_nl.properties). This is similar to using the XML file, except that it creates multiple files (one per language)
2. I'm a bit hesitant on using Symphony Sections for this. I was more thinking along the line of a content page like the Global Parameter Loader has which allows you to add parameters. Or is that what you mean?
3. Well.. you want to be able to also read the value of the Language Redirect extension, for you want to prevent that users need to store that same information in multiple parameters. But there can be a more generic approach, where I simply try to retrieve the language code from multiple sources (like $language parameter, $_REQUEST parameter and $url-language

@nickdunn: or perhaps gettext, like suggested by david :)

@david: regarding the second point... do I understand it correctly if the implementation would be something like Multi-Lingual Static Section, of which the content (filtered on language code) is added as parameters?

It feels like there is some overlap in Static Sections, Custom Preferences and Language Parameters extensions...

@Remie To be honest: I don't know. I agree there'd be some overlap with the extensions mentioned but I was not thinking along the lines of a "Multi-Lingual Static Section, of which the content (filtered on language code) is added as parameters".

I was simply (naively?) thinking about a (Section/tables-) setup where 'labels' would be managed as Symphony Entries… But really: I am no hard-core developer and approach this much more from a UX/Design/Front-end perspective. I'll leave the internals to the pros :)

@david: the discussion is currently still on the UX level :)

Initially I tried using a Resources / Labels section with multi-lingual field. I appended a DS to each page, filtered it on language code, and used a utility template to retrieve the value.

My problem with this approach was that, from a UX point of view, Symphony sections are just not that convenient for storing dozens of single word key/value pairs. Additionally, I wanted the correct values to be available as parameters instead of using xsl:call-template with a "key" parameter to retrieve a value:

<h3><xsl:call-template name="gettext"><xsl:param name="key" value="'title'" /></xsl:call-template></h3>

is less intuitive than

<h3><xsl:value-of select="$title" /></h3>

So I came up with the XML file and a small extension. The XML file is easy to maintain for developers, but it has some downsides: it requires a release (or at least some FTP / SCP / SSH effort) so it can only be edited by developers who might not be the correct owners responsible of translating content.

The next step would be to go back to the Symphony backend. From a UX perspective, I have four options:

1. Like members extension, allow users to select a section and have them define the key, value and language code fields.
2. create a pre-defined section
3. create a custom database table in which users can enter key/value pairs and language code, and add a custom view to the navigation
4. option 3, but keep using the XML file instead of database table

As a UX designer, which option would you prefer?

@Remie I have to go to sleep but will quickly respond…

Ideally we would keep the flow as close to the familiar Symphony Way™ as possible. At the same time I don't think this should force us to use a less ideal technical implementation.

i18n is traditionally (I think mainly of gettext in this context) somewhat 'technical': it involves 'template-keys' and adding 'strings' and 'translations' in some form of repository. Most bare-bones, obviously, is the raw editing of .po files. Although there are tools like poEdit I have not seen many CMS'es that incorporate something like a po-editor.

Many developers simply provide editors a (sometimes simplified) lang.po file together with instructions on how to add translations…

All this is to say that, to me, it is not a huge issue to 'detach' the i18n of these strings from the content management.

Option 3 (or 4) seems a nice middle ground between user-friendlyness and a technically sound solution.

But, it's getting late… :)

Ok, so this settles it... I will rename the extension to gettext™ and implement a multi-file based i18n implementation. As a bonus feature, I will add a custom easy editing page.

Additionally, the extension will be decoupled from the Language Redirect extension, but will still make use of the $url-language parameter if available.

I will update the github issues list tomorrow... it is indeed time to go to bed!

What about xsl:key which is great for lookups like this?

Eerr... right... so what does this mean for the usefulness of this extension?

I don't have any real experience with xsl:key but would this not only solve the tempateing part? We'd still need an interface to manage translation strings right?

We'd still need an interface to manage translation strings right?

True... I can add an event to the extension that outputs the language filtered content as XML in order to use the xsl:key.