Multilingual support

Is there a way to retrieve the user interface language for the current browser-session in Python?

Use case / background
The language of the Viktor user interface depends on the browser setting of the en used. That means basic ui elements follow the users preferences. In practice I see that this differs for our colleagues, some use English, some use Dutch. It would be nice if we can extend that in things like UserError, progress_message and our result views. Currently we have to make a choice, which will always result in a ui with mixed languages for some of our colleagues.

I was hoping api_v1.User would return the i18n setting (like en-US, nl-NL) of the user’s session, but that doesn’t seem to be the case. Or is there another way to get this information?

Hi Rense,

Thanks for you question. This is currently not possible, so i have reclassified this topicas a feature request.
I have added it to our internal issue tracker. We will keep you updated when something changes on this topic.



1 Like

Thanks for writing out a detailed description. One thing i’m wondering though: is it important for you to enable multi-lingual support (Dutch and English) or would you prefer a single enforced language?

I’m asking this because an alternative route we could take is that the app specifies and enforces a certain language and the browser language no longer has influence on the interface language.

Great question Matthijs. Hadn’t really looked at it from that angle. I personally prefer the current way with the multi-lingual approach. But let me ask around what the product owners, stakeholders and end users prefer.


If you’re asking about the desirability of this, make sure to also provide some context on the effort it takes. Because if it takes zero effort, saying yes to this is very easy.

In order to make it truly multi-lingual, you probably also have to provide multiple texts for every ui_name on a field you have defined. This is not a singular effort, since every change you make on the textual elements caries the increased effort of translation. In short i think the stakeholders need to weigh the value of multi-lingual application support against an increased development load and thus decreased development speed.

I’m not saying that this is not worth it. It could very well be that this is very much worth it, but it is good to think critically about it. I’m very much interested to hear from you how that balance lies :slight_smile:

PS: a colleague of mine proposed recently that for multi-lingual support you simply let your browser do the translation. maybe that could be good enough?

To bump an old topic. Multi-lingual apps would benefit my company as well. I am now looking at building three apps (NL, DE & UK) for my international co-workers. Allowing the UI-name to be dynamic would save a lot of time.

Thanks for your contribution @Frank ! If we would add multi-lingual support in VIKTOR how would you want this so switch between languages?

  • based on locale of the browser
  • based on a dropdown in the interface
  • other?

renamed feature request to make it more easy to find

Description of the limitation and why it is relevant to address

As a user, I’d like to be able to set the platforms’ language manually so that

  1. I can collaborate more simply with colleagues in other countries or make tutorial and demonstration videos in another language,
  2. Automatically translate my app in different languages for ease of use by colleagues internationally

I think this is relevant for the VIKTOR platform because some user like to work in their own native language

Submitter proposed design (optional)

For item 1:
Under settings

For item 2:
Add a little flag icon like this, if the UI is available in multiple languages. Default to the language specified in item 1.

Of course, the parametrization should allow for ui names and descriptions in multiple languages.

Current workarounds

Not that I’m aware of.