feat(urlParam): new locale urlparam embedding to setup language for traductions

[ERGO1995]

SUMMARY

I picked up an existing PR that was no longer progressing (PR 30318). The idea is to make the language dynamic and configurable in the context of embedding a dashboard. To achieve this, I added a "locale" key in the urlParams, which allows passing the desired language code. Thus, in an embedding context, you just need to manage this code dynamically so that the user can view the dashboards in their preferred language.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

locale: 'en' :

locale: 'fr'

TESTING INSTRUCTIONS

You can modify the "locale" key here:

<script>
    supersetEmbeddedSdk.embedDashboard({{
        id: "{dashboard_uuid}",
        supersetDomain: "{SUPERSET_URL}",
        mountPoint: document.getElementById("dashboard-container"),
        fetchGuestToken: () => "{token}",
        dashboardUiConfig: {{
            hideTitle: true,
            hideChartControls: false,
            urlParams: {{
                startDate: '2024-01-01T00:00:00',
                endDate: '2024-12-31T23:59:59',
                locale: 'en'
            }}
        }}
    }});
</script>

ADDITIONAL INFORMATION

• [x] Has associated issue: PR 30318
• [ ] Required feature flags:
• [ ] Changes UI
• [ ] Includes DB Migration (follow approval process in SIP-59)
  • [ ] Migration is atomic, supports rollback & is backwards-compatible
  • [ ] Confirm DB migration upgrade and downgrade tested
  • [ ] Runtime estimates and downtime expectations provided
• [x] Introduces new feature or API
• [ ] Removes existing feature or API

[codecov[bot]]

Codecov Report

:x: Patch coverage is 46.66667% with 8 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 72.88%. Comparing base (76d897e) to head (acfab9c). :warning: Report is 3184 commits behind head on master.

Files with missing lines	Patch %	Lines
superset/views/base.py	22.22%	6 Missing and 1 partial :warning:
superset/app.py	83.33%	1 Missing :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #31646       +/-   ##
===========================================
+ Coverage   60.48%   72.88%   +12.39%     
===========================================
  Files        1931      558     -1373     
  Lines       76236    40360    -35876     
  Branches     8568     4239     -4329     
===========================================
- Hits        46114    29416    -16698     
+ Misses      28017     9850    -18167     
+ Partials     2105     1094     -1011     

Flag	Coverage Δ
hive	47.16% <46.66%> (-2.00%)	:arrow_down:
javascript	?
mysql	71.87% <46.66%> (?)
postgres	71.93% <46.66%> (?)
presto	50.92% <46.66%> (-2.88%)	:arrow_down:
python	72.84% <46.66%> (+9.34%)	:arrow_up:
sqlite	71.44% <46.66%> (?)
unit	100.00% <ø> (+42.36%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rusackas]

Looks like this might just need npm run lint-fix from within the superset-frontend directory.

[ERGO1995]

@rusackas alright, I’ll try this approach. I spent some time last week working on currency management using the "locale" key in the urlParams. I'll push the code to this branch this afternoon; it’ll be cleaner than creating a separate independent PR.

[ERGO1995]

@rusackas for the company I work with, and I believe others in the community might also need this, I would like to make it possible to translate chart titles on a dashboard. This is something that isn’t currently dynamic with the language selection. Have there been any ideas or discussions on this topic?

[EnxDev]

@ERGO1995 could you please add a link to the associated issue in the additional information?

[ERGO1995]

@ERGO1995 could you please add a link to the associated issue in the additional information?

@EnxDev Yes, it's done.

[rusackas]

Running CI, but it doesn't look happy so far.

Regarding translations for "dynamic content" (chart titles, dashboard titles, column names, dataset names, etc., etc.) there hasn't yet been a SIP around this. It's been talked about, but nothing formalized. Some people want to do it with automated API based workflows, some want to just have a translations table that uses UUIDs for all assets as a reference, some want to commingle it with the current translation files/build process. Unclear if it should be tied to any new UI, or if the process is "invisible". If you have ideas, contributions/discussion would be welcomed.

[ERGO1995]

Running CI, but it doesn't look happy so far.

Regarding translations for "dynamic content" (chart titles, dashboard titles, column names, dataset names, etc., etc.) there hasn't yet been a SIP around this. It's been talked about, but nothing formalized. Some people want to do it with automated API based workflows, some want to just have a translations table that uses UUIDs for all assets as a reference, some want to commingle it with the current translation files/build process. Unclear if it should be tied to any new UI, or if the process is "invisible". If you have ideas, contributions/discussion would be welcomed.

@rusackas I tested this modification in charts.jsx:

updateSliceName={t(props.updateSliceName)}
sliceName={t(props.sliceName)}

Then, I created a file superset/superset-frontend/src/dashboard/customTrads.ts like this:

import { t } from '@superset-ui/core';

// List of translatable titles
t('Production turnover');
t('Production cost');

Next, I executed the following commands in the backend container:

pybabel extract -F superset/translations/babel.cfg -k _ -k __ -k t -k tn -k tct -o superset/translations/messages.pot .
pybabel update -i superset/translations/messages.pot -d superset/translations

Afterward, I recompiled the translations in both the backend and frontend, as the chart titles in the dashboards rely on the messages.json file. Now, when selecting the language, the translations I configured in messages.po are correctly applied once extracted.

I'm not sure if this is the best approach, but with minimal changes to the existing code and using a custom file, it seems to achieve the desired outcome.

[ERGO1995]

@rusackas Regarding the CI, it seems like it doesn't like the declaration of local-currency. Maybe it's not in the correct place where I declared it? It was working locally, though.

[swapnil0545]

@ERGO1995 This is a very good feature indeed and enables the access of translation within the embeded dashboard. We should work on getting it in the main branch.

[rusackas]

We should work on getting it in the main branch

Agreed! It definitely needs a rebase, and then we can figure out what it'll take to get through CI after that.

[rusackas]

This one needs a rebase, and may warrant some additional eyes.... adding more reviewers!

[ERGO1995]

Ok, i rebased and updated some code like you wanted @mistercrunch @rusackas

[rusackas]

Approving CI to run 🤞

[Vitor-Avila]

hey @ERGO1995 @rusackas @mistercrunch I think this is a super nice addition to the tool!!! I definitely don't want to drastically change the direction here (or increase complexity) but I was wondering if maybe instead of having this handled through a URL parameter, if this could be taken from a user property?

If we think about Superset (non embedded context) currently the translation setting is "global" (not per account). If we were to have that set on the account level, then this would be dynamic/automatic for logged-in users, and then perhaps the approach to make it work with embedded would be to add a new key to the guest token payload that specifies the guest user language?

I'm not against the URL param approach, but I think we'll eventually get to the point where Superset has per-user language, so I'm wondering if we want to tackle this problem for both logged in and embedded.

Thanks!

[ERGO1995]

hey @ERGO1995 @rusackas @mistercrunch I think this is a super nice addition to the tool!!! I definitely don't want to drastically change the direction here (or increase complexity) but I was wondering if maybe instead of having this handled through a URL parameter, if this could be taken from a user property?

If we think about Superset (non embedded context) currently the translation setting is "global" (not per account). If we were to have that set on the account level, then this would be dynamic/automatic for logged-in users, and then perhaps the approach to make it work with embedded would be to add a new key to the guest token payload that specifies the guest user language?

I'm not against the URL param approach, but I think we'll eventually get to the point where Superset has per-user language, so I'm wondering if we want to tackle this problem for both logged in and embedded.

Thanks!

I don’t want to say anything wrong, but doesn’t the LANGUAGES Feature Flag already allow users to switch from one language to another?

[Vitor-Avila]

I don’t want to say anything wrong, but doesn’t the LANGUAGES Feature Flag already allow users to switch from one language to another?

I know it's a config in config.py, but I thought it was something applied across the entire tenant (not something persistent per user). If that's already the case, then I think we're good

[mistercrunch]

From my understand, the admin-set config defines which languages are made available for users to see (which flags show in the menu), and switching the flag gets the locale variable set for the user session.

Now the whole babel implementation is fairly complex, given that we inherit the foundation from FAB and build upon it. Note that FAB has its own set of error messages and UI-related component strings that need to be inventorized and translated. The whole frontend part is bolted on the FAB/babel implementation on our side, adding a fair amount of complexity to the whole thing.

[rusackas]

Hi @ERGO1995 👋

This PR has merge conflicts and has been inactive for about 6 months. Converting to draft until resolved.

There was good discussion with @mistercrunch on this feature. When you have time, please rebase on master to resolve the conflicts and continue the conversation.

If you're no longer able to work on this, let us know and we can close it.

Thanks for your contribution!