alex-poor commented on issue #32854:
URL: https://github.com/apache/superset/issues/32854#issuecomment-4600200170
Hi all — I know this was closed, but given the continued interest (and
@khashashin's note about reopening) and my own emergent need for this, I've
tried to pick it up and opened a draft PR: apache/superset#40679. If there's
still appetite then I hope this might be a good reference point to move it
forward.
I read above comments carefully, and the draft PR follows the direction this
thread converged on (rather than the original table-based design):
- A configurable `TRANSLATION_HOOK` `(default_text, locale, **context) ->
str | None` is the only integration point. **Superset core does not store
translations** — the hook decides where they live (static map, external MT
service, a DB table, gettext `.po` catalogs, …), keeping core minimal as
@mistercrunch and @rusackas suggested.
- A `{{ i18n('...') }}` Jinja macro for templated fields.
- Gated by an `ENABLE_I18N_ASSET_TRANSLATIONS` feature flag and a
multi-language `LANGUAGES` config, so single-language deployments pay nothing.
- The canonical stored name is always preserved — edit flows operate on the
canonical value, so a translation can never be persisted over the real name.
Missing/erroring hook falls back to the original text.
Localized surfaces: chart/dashboard lists & cards, dashboard header, chart
panel titles, "Recents" cards, and `{{ i18n() }}`-wrapped fields. Storage and
authoring UI are deliberately out of core; the PR includes a self-contained
DB-backed reference under `examples/` to show end-to-end authoring.
**Scope note — what the draft PR does not cover yet**: The original proposal
envisioned translating all chart text including axis labels and metric labels.
This PR deliberately starts narrower: it auto-translates the names/titles that
appear across the UI — slice_name, dashboard_title, and recent-activity item
titles — plus anything an author explicitly wraps in the new {{ i18n('...') }}
Jinja macro. It does not yet automatically localize axis titles, metric labels,
column verbose_names, or native-filter names, since those live inside chart
params/form_data and dataset metadata and need a per-field strategy. The
resolver and hook are designed to extend to those fields; I'd propose landing
the names/titles read path first and layering the deeper form_data/label
coverage in a follow-up, so each step stays reviewable.
I'm happy to take this through the proper SIP process — should I (re)start a
`[DISCUSS][SIP-161]` thread on `dev@`, or is reviewing the draft PR here the
better next step? Thanks to @pomegranited and @bmtcril for the original
proposal and interesting design discussion.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
