pomegranited commented on issue #32139:
URL: https://github.com/apache/superset/issues/32139#issuecomment-2687226405
Thank you @mistercrunch and @eschutho for laying out these specific
requirements. This is really good.
I'll spend some time in the coming weeks to draft a new SIP, so please keep
these requirements coming!
Here's some initial thoughts and questions.
> Another consideration here as we've been looking into options is that for
metadata (chart and dashboard titles) that are used in CRUD searches, the
lookup needs to be able to go both ways, so from the dashboard_title in French
or Spanish, one would need to be able to find the dashboard that has that title.
I haven't looked at how CRUD searches currently work, but will try to cover
this use case with my new proposal.
If my current language is Spanish, do I need to be able to search for
French-translated dashboard titles? Or is it enough to be able to find the
Spanish terms in dashboards?
> A bit more about how this could be achieved with jinja. Where a dasbhoard
title is "CompanyX Revenue Dashboard", someone could input a jinja macro as in
"CompanyX {{ i18n(string_id="rev_dash", en_text="Revenue Dashboard") }}".
Something like this feels achievable, and we could even support inline
translations like this:
`"CompanyX {{ i18n(string_id="rev_dash", en_text="Revenue Dashboard"
es_text="Panel de ingresos") }}"`
Is that desirable at all? Or is it better to keep it simple, and only
support a single default text value? Might also bump up against database field
lengths if we try to do too much here.
Using jina templates puts the onus on dashboard/chart authors to:
* keep their `string_id` values unique for a given term
Mitigation? Authors may want to re-use terms across multiple assets, so
maybe we do nothing here.
* use correct jinja formatting
Mitigation: Can check formatting on save.
* provide translators with a list of `string_id` values that need
translating, and context details for each string
Mitigation: Can support a `description` field in the `i18n` structure too,
and add a mechanism to pre-populate the Translations table from existing assets.
> Wanted to add more thoughts on 3 high level approaches and their related
pros/cons:
The ORM approach could harm performance for single-language installs, so OK
to reject that option.
I guess namespacing could be done with asset UUIDs? That would also mean the
`string_id` only needs to be unique within the context of the chart or
dashboard, which could help the authors. But it also limits any re-use points
of translations: e.g if `string_id="rev_dash"` is used in multiple charts, then
it only needs to be translated once.
So I'm inclined towards implementation simplicity, with single k/v lookups
per term.
--
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]
