Symphony.

A new XSLT utility, “Front-end locale” 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.

Great job. It would be great if I can declare some kind of global variable instead of passing the language code on every function call.

First off: you will need EXSL support for functions to work like this. Second: I’m looking for a way to lose the need for that namespace … on the other hand, it is nice that it will never conflict with other functions this way!

That’s definitely a easy change to do.

Change

<xsl:param name="lang" select="''" />

to

<xsl:param name="lang" select="$language" />

And on master.xsl define the $language variable.

That’s also possible! As long as there is some language code in there!

Wrote a very similar utility myself recently. I’d think a lot of users of this would use it together with the Language Redirect extension, which provides a $url-language variable.

I ended up using a secondary source file loaded using the XSLT document() function instead of a datasource, and loading the complete nodeset of strings for the current language into a lookup variable.

This also works nicely for localizing navigation items generated from Symphony pages.

Front-end locale updated to version 1.1 on 13th of November 2010

Froded, what is the performance impact on loading that extra xml document? Is the parser smart enough to only load it once even when it’s called multiple times?

In my function i’d be calling it twice already. That could be optimized, but still, on a page with multiple localized strings the function itself would be called for each string, loading the xml document once or more each time.

Or would you load the xml once and put it in a global parameter ….

And while i was typing it hit me ;)

All of the above is to be ignored

I have updated the utility but i have kept the “logic” the same because i want to have a “fallback to the input string” when something isn’t localised!

Zimmen, loading it into a global variable was what I meant, yes :) So the XML document is only loaded once.

As for fallback values, I just use the lookup key as the default locale value. So if a key does not exist in the current locale XML, I’ll just output the key itself. This is how localization in Symphony itself works.

Yes, that’s how i’ve done it in this update as well. I’ll go and test whether using the XSL key improves performance a bit… it should!