New supported languages for AWS QuickSight Q

[Altay_Akkus]

Hey,
I have a potential use-case for QuickSight Q at my job, but unfortunately there is a dealbreaker.
Q is primarily marketed at Business decision makers, who want to query their data but are not familiar with BI reporting, or SQL syntax.
I live in Germany, and while Q offers me the possibility to quickly formulate querys, this just is not going to happen for the primary audience of this tool.
Many decisionmakers don’t know English, and if they do they find it exhausting to write complex statements like “Give me the average cost sorted by the product group”, as they would probably have to Google a few things each time, which totally negates the sweet “everyone can query via written text in seconds” user experience.

So I have a quick proposal for adding new languages without making this a year long product:
I have tested out that writing my querys in German, translating them via AWS Translate into English, and then piping this into QuickSight Q works surprisingly well.

So maybe you could add a setting to Q for adjusting the default language, the logic behind it could look like this:

So if you submit a query, it checks if your config has a language selected other than default English, if so it sends a query with your Query, your custom language to AWS Translate.
The Action TranslateText (see AWS Translate docs) supports TerminologyLists, you can feed in special cases where you want to define the translation. The documentation has a great example with Amazon Familywhich in French shall be translated to “Amazon Familie” not “Familie Amazon”.
This should fit well with the Visual Data Labels in QuickSight which make querying in Q so much easier.
So each label value shall not be translated, and left as it is, so Q can do its magic.
The TerminologyList shall be compiled each time the user modifies the Data Labels, as this may not happen that often that speeds up things and prevents unnecessary reads at each inference.

I hope my proposal may help you to implement this, I really want this and think it would add a huge value to QuickSight Q.

Regards

PS: I am willing to be billed for the use of AWS Translate, please just make this happen

[marakagi]

@zacwoodall Thought you might be interested in this post.

[zacwoodall]

Thank you for the tag! I’ve shared with the team.

[Altay_Akkus]

Awesome! If you should have any questions just ping me up.

[zacwoodall]

We took a look at this, and here are some initial thoughts.

1. A big part of today’s experience is entity recognition and disambiguation. In real time as a user types, Q interprets each word and applies it to the dataset. Recognized words are highlighted with an underline. Users can and frequently do click underlined terms to change their mapping to a different piece of data than Q originally selected. For example, a search for “shoes sold us last year”. May map to a variety of types of shoes, boots, sandals etc. ‘shoes’ may map to the product category and also match many specific product names. ‘us’ may refer to our company or the united states. Users scan see field names and values and select what the mapping should be in order to get an accurate result. All this happens before the query is submitted.

2. If the data contains foreign language fields, this model will break the match. For example ‘shoes’ in Spanish is ‘zapatos’. I put the same example from above into Google Translate, and here’s what I did, “los zapatos nos vendieron el año pasado”. So in this case, once converted to english, ‘zapatos’ would not match to any instances of the word ‘zapatos’ in the underlying dataset. Note here that the translator has also made an unwelcome disambiguation. The word ‘nos’ means ‘us’ not ‘united states’, assuming this was the user’s intent, that intent is now lost through translation.

We want to avoid delivering a sub-par experience to non-English customers. Our focus for the time being is on making a fast, simple, and powerful Q experience in English. There is still important work customers have asked us to do here in order to support very common cases. Once we have this in place, we’ll be in a good position to start bringing a service in additional languages.

[Altay_Akkus]

@zacwoodall

If the data contains foreign language fields, this model will break the match. For example ‘shoes’ in Spanish is ‘zapatos’. I put the same example from above into Google Translate, and here’s what I did, “los zapatos nos vendieron el año pasado”. So in this case, once converted to english, ‘zapatos’ would not match to any instances of the word ‘zapatos’ in the underlying dataset. Note here that the translator has also made an unwelcome disambiguation. The word ‘nos’ means ‘us’ not ‘united states’, assuming this was the user’s intent, that intent is now lost through translation.

Wasn’t this the thing with the Data labels and the TerminologyNames? Can’t really tell, im obviously not that into your backend

@zacwoodall

A big part of today’s experience is entity recognition and disambiguation.

Totally get that part, but lets say the following:
I have data of production machines, they save how many parts they produced, their machine name, and a timestamp. The schema is datapoints[id, name, partsProduced, timestamp]
In QuickSight I say that the partsProduced field has these labels in German:
Stückzahl, Menge an Produkten etc. pp.
And the name field has the labels of “Maschinenname” “Maschine”

Now my user would type the following query into Q:
Zeige mir die Stückzahl je Maschine im Jahr 2022 which means “Show me the quantity by machine in the year of 2022”

I send this string to AWS Translate, including my TerminologyList which consists of:

[{'term': 'Stückzahl', 'translated': 'Stückzahl'},{'term': 'Menge an Produkten', 'translated': 'Menge an Produkten'}, {'term': 'Maschinenname', 'translated': 'Maschinenname'}, {'term': 'Maschine', 'translated': 'Maschine'}]

So AWS Translate excludes these words from the translation.
So it should come up with something like this:
“Show me the Stückzahl by Maschine in the year of 2022”

@zacwoodall

Recognized words are highlighted with an underline. Users can and frequently do click underlined terms to change their mapping to a different piece of data than Q originally selected.

Isn’t this based on the name of the Label, which stays the same regardless of the default language of Q? Wouldn’t Q detect this, as the label text is never changed, regardless if it is translated via AWS Translate or not?

If Q would detect words such as “ascending” or “alphabetically” I would understand what you meant, but since it seems to be only based on the Label names, which are even correctly detected if you just type bla bla bla student name bla bla
Problem with this bogus query that Q does not understand is that he wants to know what the hell bla bla means As Q detects bla bla bla as one object that is not classified as anything, student name as one object that he has alternative suggestions to, and bla bla a different object that he also does not know.
Picture
This problem would have not come up if bla bla bla would been passed to Q as formally correct english text, because it was translated by AWS Translate before. (if bla bla bla was German/Spanish for something)

[zacwoodall]

While I’m not able to go into deep detail about the architecture of Q’s system here, or the future direction we’re going to build it in, I can say that this approach isn’t a fit for what we most need to do to help customers right now. Additional language support is important, and we will work on it in the future.

[Steph]

Hi @Altay_Akkus, thanks for taking the time to share your detailed use case. Since we’ve noted this as a feature request I’m going to archive the question.