options for text re-using with multi language support

options for text re-using with multi language support

I am having a kind of questionnaire with a lot of questions. I want all of those questions to be localized (in two languages).

Every question is placed on two seperate pages, but might be polaced on more. Currently I have one Web block for shwoing the questions and the answers and I have a Web Screen for filling in the questionnaire (giving answers to the questions).

Without multiple languages I had a lot of site properties, one for each question. But this doesn't work as these are not translatable. So I need to find another solution.

I could just type in the questions in both locations and then translate both instances as well. But I don't like to have multiple instances of the same text, especially when I need to translate them too. It will quickly go out of sync.

Here are the options I can think of, but I might miss some:

(1) Have static entities and use translations on them. For every question I will have an expression that gets the question based on it's identifier.
Advantages are that I can easily drag the questions from the Data tree into the pae at the right spot and it will even show the question itself as an example.
Another advantage is that it's pretty easy and quick to enter, edit and see an overview of all questions through the Records tab of the "More..." popup window for static entities.
Disadvantage is that for every question the page has to go to the database to fetch a single question. With about 30 questions, that is probably not the best idea. How fast will this be? Will there be some caching involved or can I configure that?

(2) Make an action and set it as a function. The action will have a single Switch (or maybe multiple Ifs) and will set an output parameter based on an incoming parameter.
Advantage is that it is all in memory and so quicker than option (1).
Disadvantages are that there is no overview of all questions, it's really tedious to enter or edit questions, on the Web Screen you will only see "Expression" and cannot quickly see which question it is, you need to enter the expressions manually (no drag and drop).

Options (1) seems to have all the advantages, but the many database calls worries me. I might miss an even better option. Please tell me...

What do you think?
Hi Rodi,

After reading your scenario I would definitely go for the static entities option!

Performance is not really an issue when you're fetching 30 questions from the database. That will only become an issue when you're going for millions of users or millions of questions.

In any case, you can easily cache the screen or the query that fetches the questions by setting the "Cache in Minutes" property. With that you'll make sure everything stays in memory and is super fast ;)

Hope this helps,
Thanks for the reassuring answer. I was hoping this was the way.

About caching, I have a web screen that has all these questions and for every question an input field. Is it possible to cache these kind of web screens too or will that affect the posting of the input fields?

But first I will just use the static entities and see how performance is; caching might not even be necessary.
Hi Rodi,

Caching will work on any screen, regardless of it having inputs or not: as long as another request for a screen is made within the cache minutes window and the parameters to that screen are the same as a cached version, you get the pre-rendered (i.e. the cached) version.

The caching is only for the screen fetching: there is no caching for the post-back, which always works normally (i.e. it always submits). That's why you can have a form in a cached screen.

Doesn't it mean that you can have outdated info in input fields?

Let's say I am editing a product on the product_edit page. It is a cached page, but it was not in cache before. It will be cached now.
I change some fields, submit the form and the product gets saved.
Then it will redirect to the same page (or I will just navigate to it) so the page has the same input parameters set.

Will I see the old values or the new values?

Yes, that is correct: you would have inputs with the "old" value. But that problem is not different from having a screen with a Show Record that displayed outdated information - it's a side effect of having cache that only looks at a timeout and different inputs.

In the end, it comes down to the developer to decide where it does make sense to use caching or not: maybe on small screens of highly mutable information it does not.

In any case, should you need to invalidate this cache at any time, simply use the EspaceInvalidateCache action (you can tick it from inside the (System) producer) when you know that some cached screen somewhere on your eSpace will have stale information.


Ah yes, thanks for the input. I will look into it and probably use the invalidation of cache too.