International Dashboards, how to translate dashboards.

[Crichter141]

Hi there, I have a question on how other users may translate between languages on dashboards.  I'm aware of the post link below and it's how we have proceeded, but I can't help but think Qlik would be working on the ability to translate - being an international company.  An extension or anything to make it easier.

https://community.qlik.com/t5/Qlik-Design-Blog/Making-a-Multilingual-Qlik-Sense-App/ba-p/1678131

In our example, we have English and German customers.  What have other companies done.

[Or · Accepted solution]

The method described in your post is pretty much the only option. Any form of automated translation of unknown content with unknown context would likely be doomed to fail, after all. If you do trust automated translation, you can skip the step of manually translating the content and whip up a script to do it for you using a translation service API.

[Crichter141]

Or,

Thank you - so follow-up question.  How would you suggest working the indices with Labels? 

The problem with using this method if you use labels and the language index - the label reads something like:  only({<LANGUAGE_ID = {'O005'} >} $(vLanguage) )

My thought is to request the developers (me included) to comment the expressions as a standard.  Otherwise we have to hunt through each expression for fields that need updating.  Or we could put a cross walk in the application and hide it from the end users. 

Wondering if anyone's developed a process around using this index translation - we've only done it with one app but it's sort of growing faster and faster and it's hard to track all the translations.  Our current table is 437 lines - which is pretty small except when you're looking through it for maintenance.  Ideas?  Other links?  Thank you for your help.  Original question answered.

[Or · Accepted solution]

I used to have apps that were multilingual and used a translation index. I have to admit I hated it, for the exact reasons you describe (and also because every new term had to be translated before it could be used, which is super clunky). Luckily for me, the organization eventually decided that English was good enough for our Qlik apps...

I can think of several ways to work around the issue of the header being obscure when developing, though none of them feel great.

1) Use a clear Master Item name whenever you can

2) Comment the values as you suggested

3) Load the full translation table into a sheet (which could be hidden from non-developers) as an easy way to look it up, as you suggested

4) Use external options to translate, such as a Babylon dictionary that would access the same translations

I haven't ever tried to do this myself, but I think you might be able to use something that reads the app metadata (such as Document Analyzer) or API to isolate any master items that have a header not matching *LANGUAGE_ID*, though this wouldn't detect typos or copy-paste errors when a field is duplicated by the ID isn't changed. Perhaps you could create a table containing all of the master items, limited to a single row (Top 1), export that with two different language selections, and then compare any headers that didn't change? Just spitballing here, perhaps others would have better ideas or proven methods.