- RedDot CMS Blog
- 22.02.2017
- EN
rdb: Using RenderTags 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 RenderTags.
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 RenderTags 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 :
RenderTags <%!! 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 :
RenderTags <%!! 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.