mistercrunch commented on issue #32854: URL: https://github.com/apache/superset/issues/32854#issuecomment-2790649473
From a deep conversation with PMCs today - there seemed to be traction for a simpler solution around a more generic "translation hook", where administrators would be free to implement a generic function to hook up with an external translation service. The high level idea is that you would have some sort of `TRANSLATION_HOOK(text_to_be_translated, context_object)` function defined in something like `superset_config.py` and externalize the translation process through that. That hook would assume the external service is in charge of accumulating strings to be translated, memoization, and serving the text -> do whatever makes sense to you in there. There were deep discussions about whether we're talking "all or nothing" approach, asking whether - in a given superset instance - all metadata or none should be flagged for translation. My take on this is that I think there needs to be a way to flag which strings/objects need or don't need to be translated - whether it's through jinja intrumentation, or property checkboxes "flag this dashboard for translation". Also some talks/questions about whether the administrator decides, the user decides or the external service decides what need to be translated. On my side, and stepping back a little - I'm still seeing some benefits to the general idea of "framework support for jinja templated fields in Superset models", where we define a set of dynamic fields (through things like `Datashboard.template_fields = ['dahboard_title', 'description']`), and allow people in their instance to overload the jinja context with functions like` i18n` or `dashboardMetadataAccessor` or whatever make sense. This would open and widely solve "dynamic properties" across the board. One more thing. Nothing here yet solves translating external data coming from the database, meaning there's still a gap in the solutioning (assuming the goal is 100% i18n). Sure you can translate the title of the dashboard, the name/label of the dimension and metrics, but what about the content returned by the database? A simple example would be: - dashboard name "Demographics by country" -> "Demographiques par pays" - dimension name "Country" -> "Pays" - metric name "Birth rate" -> "Taux de naissance" - but what about DATA!?!?!?? "United States" -> "Etats-Unis" - are we disregarding something important here? As in we go through all this trouble and it's impossible to achieve 100% i18n... Do we need a `DATAFRAME_I18N_HOOK`? Or does it even make sense to send result sets cells through `TRANSLATION_HOOK`? -- 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: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
