topic Re: Multilingual titles make app extremely slow in App Development

Multilingual titles make app extremely slow

David_K1 — Mon, 06 Oct 2025 06:17:52 GMT

Dear Qlik Community

We are using an approach very similar to the one described in this post to make our app multilingual.

However, we found that this drastically decreases the performance of dashboards up to a factor of 2-3. E.g. a dashboard with a table with 30 columns would load in 4 seconds without translation of the column titles. Adding translations increases load time to about 12 seconds.

We use the following expressions in the label:

=only({<[Language.Code]= {'Street'}>} Language.Text_$(v_Language))

=only({<[Language.Code]= {'City'}>} Language.Text_$(v_Language))

We set the language in the variable v_Language which then determines which column is used, e.g. Language.Text_EN, Language.Text_DE etc. Our datamodel is quite complex with almost 2000 fields (we are trying to improve that), but I would not expect this to be a problem for the translation. As in the linked post, our Language table is an island table.

Does anyone have an idea why this performance decrease happens and how it could be fixed?

I am using Qlik Sense Enterprise on Windows, Nov 2024 Patch 9.

Re: Multilingual titles make app extremely slow

robert_mika — Sun, 05 Oct 2025 05:26:10 GMT

Do you have translation of all columns or just the text(titles)?

Re: Multilingual titles make app extremely slow

David_K1 — Mon, 06 Oct 2025 06:16:06 GMT

I also have translation of the data, but this seems to be less of a performance issue. The main issue are the labels (I would have expected it the other way around, that the labels make a small contribution to the performance).

Re: Multilingual titles make app extremely slow

David_K1 — Mon, 06 Oct 2025 08:50:33 GMT

I made some more tests and the complex data model definitely is an issue. If I reduce the data model from 2000 to 650 fields, load time is reduced to about 4 sec. with translation / 3 sec. without (from 12 / 4 sec.).

I probably should split the app into multiple apps each with a simpler data model, but that's not an easy task.

Re: Multilingual titles make app extremely slow

rwunderlich — Mon, 06 Oct 2025 14:37:18 GMT

I assume your v_Language variable is an expression like

=Minstring(Language)

Can you post your v_Language content? Confirm that you have a leading "=" in the definition.

The Language listbox and the expressions that reference should be in an alternate state, for example "LanguageState". Then reference that statename in your expressions like:

=Minstring({LanguageState}Language)

=only({LanguageState <[Language.Code]= {'Street'}>} Language.Text_$(v_Language))

Consider analyzing your App with QSDA Pro to see where the compute time is going.

-Rob

Re: Multilingual titles make app extremely slow

David_K1 — Tue, 07 Oct 2025 07:42:41 GMT

Thanks a lot for your reply, Rob!

We don't use a field selection for the language, v_Language is a variable defined in the script:

Set v_Language = 'DE';

Then we have a variable eTranslation that we use for all translations (in order to not repeat the code):

eTranslation = only({<[Language.Code]= { '$1' }>} $(='Language.Text_'& $(='v_Language')))

We use the variable in the label like this:

=$(eUebersetzungSprache(Street))

I have tried several options but without any significant performance increase:

not using eTranslation but directly using =only({<[Language.Code]= {'Street'}>} Language.Text_$(v_Language))
defining v_Language in the editor and adding "=" (it does not have a "=" when defined in the script)
defining eTranslation with different syntax around v_Language: only({<[Language.Code]= { '$1' }>} $(='Language.Text_'& '$(v_Language)'))

So far, the only things that helped were:

removing the translations from the labels (just adding a string as label)
adding a leading "=" to eTranslation -> then the translation does not work, but performance is restored
reducing the complexity of the data model

I also run a QSDA analysis which showed the table loads in 2 sec. (with translation) vs. 0.6 sec. (without translation). Interestingly, it only gives a calc. time of about 0.03 sec per label (with translation) vs. 0.001 sec. (without translation). For 30 labels this adds up to about 1 sec. (close to the 1.4 sec. difference), but when I measure the performance in the UI, the difference is much larger (about 10 sec. vs. 3 sec.).

Would you expect any difference in performance when using alternate states instead of a script defined variable for v_Language?