Who, what, when, where and why

Get the latest news about Sourcefabric software, solutions and ideas.


Newscoop recipe part two: handling multilingual strings in templates

String | Photo credit Flickr Stuart B (CC BY-NC 2.0)
String | Photo credit Flickr Stuart B (CC BY-NC 2.0)

This post is a follow-up to a recently published article Newscoop recipe: handling multilingual strings in templates by Micz Flor. I propose another way of doing it, which - of course - I believe is the better way to go. Feel free to take sides in comments or on Facebook!

Using the built-in Smarty function {{ config_load }} (http://www.smarty.net/docs/en/language.function.config.load.tpl) we can also achieve separation of multilingual strings from the template code.

We who work with Newscoop templates for a long time know how much a big P in the A it used to be when dealing with multilingual templates. Yes, content is translatable, so the site structure in the default language transforms beautifully into a tree with multiplied branches. Newscoop handles language context naturally so the article is the same with the unique id regardless of the language and different translations that are just versions of the content, and sections, issues, publications, topics - everything works great and supports that logic.  

But, static template strings were posing a problem. We had to check them for language, context and depending on that, show the appropriate words dor every string, everywhere. Not anymore!

So, to come back to {{ config_load }} - with this approach, every language can have it's own .conf file, and we can name them English.conf, German.conf etc. Depending on the language of the context, we can load the appropriate file, easily, like this:

{{ config_load file="{{ $gimme->language->english_name }}.conf" section="Category" }} 

Take this template for example - category.tpl. As the publication is localized into four languages (en, ru, es, de), it has 4 'if' conditions for every string.

{{ include file="_tpl/_html-head.tpl" }}


{{ $gimme->topic->name }}


  {{ if $gimme->language->english_name == "English" }}
    Article published under {{ $gimme->topic->name }} Category
  {{ /if }}
  {{ if $gimme->language->english_name == "Russian" }}
    Статьи, опубликованные под {{ $gimme->topic->name }} темы
  {{ /if }}
  {{ if $gimme->language->english_name == "Spanish" }}
    Los artículos publicados en {{ $gimme->topic->name }} tema
  {{ /if }}
  {{ if $gimme->language->english_name == "German" }}
    Artikel zum Thema {{ $gimme->topic->name }}
  {{ /if }}


When we apply this new approach, the template looks like this:

{{ config_load file="{{ $gimme->language->english_name }}.conf" section="Category" }}
{{ include file="_tpl/_html-head.tpl" }}


{{ $gimme->topic->name }}


  {{ #articlePublishedUnder# }}
  {{ $gimme->topic->name }}
  {{ #category# }}


The English.conf can look like this:

#this is the config file for English
# global strings
publishedOn = "Published on "
filedUnder = " Filed under "
comments = "Comments "
multiPOIs = "Map with geo-locations from listed articles"
#Strings for Category page
articlePublishedUnder = "Articles published under"
category = "Category"
#Strings for Archive page
archive = "Archive"

Advantages of using this approach 

  • Using {{ #langVariable# }} syntax in a template is visually pleasing as it divides language strings from other template code.
  • Optimized solution for template multilinguality. For example, no need for 'íf' clauses to decide which .conf file to load  - we can simply name .conf files like English.conf, German.conf etc and load them as in example above.
  • Furthermore, .conf files can have sections, so in different pages we can load only the appropriate sections of the file - for example {{ config_load file="English.conf" section="Archive" }}
  • The ability to localize template strings independently of template developers, by editing appropriate .conf file

The only problem right now is that in Newscoop 4.1 .conf files are by default stored in /configs folder in the instance root. This will be changed hopefully in 4.1.1, so we can keep .conf files in the theme's root or under it so they are still part of the theme.