rusackas commented on issue #32854:
URL: https://github.com/apache/superset/issues/32854#issuecomment-2776264375
Loving this! Lots of folks have been asking for this, and it's very much
along the lines of what @mistercrunch and I were discussing a couple days ago,
and we've talked about with others in the past. TL;DR: I'd love to see this
happen!
@pomegranited
* > May need to batch queries or use a cache for performance.
This seems essential to me... otherwise I think we'll see some weird
performance hits, both on the site load time side, and on the metadata db's
stress level.
* > Some model fields are edited within a modal popup – so we'd want to
avoid a modal-within-modal UI.
@kasiazjc might have good ideas. I believe the AntD Popover can support
form elements, so that may work in all cases. The design trick might be to find
some sort of mechanism to open this popover on hover or right-click so we don't
drive people crazy with popovers appearing everywhere.
* > Is there a difference in how echart editors are rendered vs old-style
charts? i.e. Do they both use the data API?
The legacy charts do use a different endpoint (which has been
deprecated _forever_, but is a long tail of work)
* > Unsure how to provide translations for complex fields like dashboard
json_metadata...
I'm not exactly sure either, but it *seems* plausible if we can find a
way to templatize some of the JSON using HandleBars/Jinja.
@nytai
* > provide a hook to call out to a provider like google translate... in a
vendor-agnostic way
1000% agreed. There may actually be many options for this, whether it's
an Google Translate, a managed translation provider like Transifex/CrowdIn, or
even LLMs. There have been MANY people asking where/how to integrate LLMs, and
this seems like one case where we _might_ be able to add LangChain as a
dependency, and let people configure their model. Any of these approaches would
require the UI to have some sort of "enter or approve" option to place the
appropriate translation into the DB table.
### Additional thoughts
I'm not sure where this might lead in the future, but I think there are some
intriguing possibilities. Once this is is all proven out as laid out in the
proposal, it seems like there would be a LOT of room for it to grow across the
product. Namely, nobody is *really* in love with the current translation
workflow. It's a standard, but it feels... antiquated, and has proven a bit
fragile (i.e. if someone updates the frontend code with a new/modified string,
it breaks existing translations). I could foresee a world in which ALL
translated strings live in this table. The challenge would be to make sure that
the UI could accumulate the required strings and fetch them in a batch... with
some sort of graceful loading so it doesn't look janky. Then _all_ the UI
strings could benefit from the translation (popover?) UI. Extending on that,
when someone fills or corrects a "built in" string (as opposed to a dynamic
one) it could be flagged as such in the table. Then it doesn't seem like a st
retch to have a script that would allow people to export a migration that
could be used to contribute these translations (as a PR) for everyone to
benefit from.
--
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]
