// you’re reading...


Using render tags to translate a site easily

In order to make up for not reading Markus’ post properly earlier, here’s a little idea courtesy of the UK Reddot day.

At some point in your illustrious career you’re probably going to have to create a project that has language variants. I know we’ve already been down that path a number of times and I’ve only been using Reddot for about 18 months. One of the things that people seem to forget is that not only does the main text need to be translated, but you’re going to have to change lots of other little bits and pieces like the labels on buttons, email addresses, Google analytics IDs… the list goes on.

What would be good is if there was one “translation” file that you could use so you only need to translate each thing once. Funnily enough, there’s a really easy way of doing this with Navigation Manager’s render tags.

As I’ve probably mentioned elsewhere, we’ve found it good practice to make the first page of your project structure an information page, rather than the actual homepage of your site. You can use this page to separate out your JS/CSS files from the main project as well as keeping some general project information, such as site owner; developer etc. etc. Now we can make this page work even harder for us.

To convert this page into a translation file, you simply need to go through your new site and find any generic text; I’ve included some examples at the bottom of this article. Once you have this list, simply add them all to your landing page as standard text fields and have a Form to allow easy translation of it all. The default value for each of these fields should be text in your primary language. By doing this you’ve now got a list of all your key words in a format that a translation editor can easily manage.

So how do we get this translated text into the rest of the project?

I’m sure this is blindingly obvious to people that have worked with render tags more than I have, but then answer is to look at using GetRootIndex() to pull translation information around a site.

We can easily pull the content of stf_hello into all our pages by including the following render tag in our other pages :

 <%!! Context:CurrentIndex.GetRootIndex().Page.Elements.GetElement(stf_hello).Value !!%>

GetRootIndex() climbs back up to the very top of the tree (which is now our translation file) and finds the value of stf_hello. Repeat this for each piece of text that you want to be able to translate and you’re done.

The alternative…

As Markus has pointed out, there is another way of doing this that means you don’t have to have the translation file as your root page. If you know the Guid of the translation file (or the page you want to grab some text from) you can use the following snippet of code :

<%!! Context:Indexes.GetIndexByPageId(Guid: 2FCD2CF681F94CC68D5AECB68C).Page.Elements.GetElement(stf_mainSponsor).Value !!%>

The reason I hadn’t originally put this in here is because it relies on you having your templates and content in the same project. As my preferred setup involves inheriting templates from one project to another, you would hit a problem as the Guid changes for each project. You can get around this by replacing the guid with a standard text field and putting the Guid as the default value so you can change it in each project.

This does, however, still leave you with a bit of work making sure you change the value of this call in each template for each project. Much simpler to just use the root page in my opinion. Still… the concept of being able to grab text from a specific file is a useful one that’s worth noting anyway.

Anyway, back to the sorts of things you could use in the translation file. We’ve included general words like : Search, Go, RSS, FAQ, True, False, Skip, Small, Medium, Large, Open, Close.

You can also use it for things like a Google Analytics ID, Webtrends ID, the site owner, a general email address or even the labels for all your red dots, so you’ve got a translatable editor interface.

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Paul Smith Paul lives in sunny England and is now technical consultant for the new, UK based branch of ecomplexx. Apart from web stuff, Paul is also interested in photography and collecting/listening to music and is never seen without his beloved ipod!


11 comments for “Using render tags to translate a site easily”

  1. I like that idea. We did that in earlier projects with a page containing all the elements and then reference them in the templates.
    But for new ones we always needed a RQL to update the already created pages.
    I would suggest using the RenderTag to get the page via GUID if you don’t want to use your “rootpage”.

    Posted by Markus Giesen | November 28, 2008, 12:28 am
  2. You could use the Guid, but doesn’t that rely upon you having templates and content in the same project?

    I think the idea of using the root page appealed to me as we’ve got a lot of projects running off one foundation. So if we made sure the translation file was always at the root, we wouldn’t have to worry about Guids changing between projects.

    Can you see I’m fixated by the idea of a generic foundation project here? ;)

    Posted by Paul Smith | November 28, 2008, 1:18 am
  3. Good point! So maybe the root is really the best/”most genericistic” solution.
    BUT you still could use the GUID by storing this 32 character long data into a standard field element (language independent for multilanguage projects).

    Posted by Markus Giesen | November 28, 2008, 12:00 pm
  4. That is a way around the Guid issue. Let me update the article to include these options…

    Posted by Paul Smith | November 28, 2008, 12:03 pm
  5. Excellent foundation advice. We ALWAYS have a SmartEdit Start Page at the root of the project. From there you can hang a special “String Table” page just for this purpose.

    As a simple variation, would an element reference not suffice? Render tags can be expensive processing and should be used judiciously, especially where standard field substitution alternatives may be available. Remeber that field substitution is done by the database and render tags are done by RQL.

    Posted by Richard Hauer | December 10, 2008, 10:38 am
  6. I’ll start my comment with my standard RedDot advice – if you are not pushing the system, the implementation probably doesn’t matter. But as soon as you do… well lets just say I wouldn’t mind seeing a comparison between using render tags and using plain elements for lets say a 100+ element translation file. My bet is on plain elements. Personally I still prefer using an ASP dictionary object to store English to placeholder value associations and just include it in every page. You are going to hit the RedDot element substitution barrier much faster than your ASP code size or execution speed. When that happens? Well I have heard of naming localised elements such that a background RQL process can populate the elements… a bit like having to roll your own navigation code to push the processing time outside of RedDot…

    Posted by Adrian Mateljan | December 11, 2008, 12:13 am
  7. Good point Adrian..

    It’s definitely something that you need to think about before creating your project.

    Apart from using Dictionary, I have used plain standard field text placeholders in the past to great effect..

    Another consideration – by having the translated text within placeholders, we were able to hand this over to content editors/administrators (by editing the default values of each placeholder) to manage translations instead of relying on developers to make the change in the code.

    Posted by Kim Dezen | December 11, 2008, 1:56 am
  8. Absolutely – anything that hands content control to authors is a blessing – to the developer and the authors – so long as it has been implemented with authors in mind. (ie no handing over “loaded guns” – only tears will result) Funnily enough, my current work involves removing hardcoded text from an existing project in order to give authors control over content that they have had to pester IT about previously…

    Posted by Adrian Mateljan | December 11, 2008, 7:30 am
  9. Oh and don’t use the GUID solution with shared projects if you embed it later.
    Unless you set this solution up from the beginning you would have to change the GUID in every child project. So the RootIndex solution is easier and the better way for content class sharing projects where you want to add this functionality after setting up the project.

    Posted by Markus Giesen | June 29, 2009, 4:16 am
  10. Also handy this one:
    <%!! Context:Pages.GetPage(Guid:19A5BCBA4A06477D8BB40BE929622BB4).Elements.GetElement(stf_moretext).Value !!%>

    Posted by Markus Giesen | September 2, 2009, 8:10 am
  11. Does GetRootIndex() require that navigation manager be enabled?

    I can’t seem to get the code above to display the text. Although we don’t use navigation manager we have had success with other render tags.

    Posted by Lise McGillis | September 23, 2009, 8:49 pm

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...