mistercrunch commented on issue #32854:
URL: https://github.com/apache/superset/issues/32854#issuecomment-2790188048
I think we're both pretty aligned on all this. Few specific comments
> I'm definitely in favor of a simple UI for these translations. But there's
a huge advantage to having an in-context UI when humans are translating these
strings, and I'd like to preserve that.
Right, context is everything. The way get_text framework keep tab of context
is they include line-of-code pointers metadata along with the to-be-translated
strings (optionally). Interestingly we decided to turn this off in our
app-translation frawework as it operated like a merge-conflict-generating
machine that was not manageable, now resorting to `grep` as the way to find
entries. Since we're not parsing source code here, we have limited ways to
identify context as the jinja code becomes some sort of runtime trigger.
Unclear how much we can do from there (meaning jinja) either through
interpreter-introspection or jinja-related self-awareness. Wouldn't be bad to
have an extra field `context` in `i18n_translation`, it's probably in-scope for
the SIP to define:
- whether we need/want that
- what the context fields looks like
- how it's instrumented (whether it's through introspection or explicitly
defined by the caller, ie: `{{i18n('Translate this!',
context='dashboard_title')}}` )
> since we're storing the asset UUID
Oh I think I had missed that from the spec, was thinking uuid was just a
unique id for the translation object itself. Now if we have the uuid of the
object itself there's a few thoughts related to that:
- can probably be introspected - probably at "entity-save-time", meaning
when we save a dashboard, we trigger a routine that uses jinja to find all of
the `i18n` calls in the various templated fields, and adds missing one to the
translation table
- would couple nicely with `object_type` for a bit more referential
integrity, though in theory we could figure this out somehow since uuids are
globally unique. My take would be to have both `object_uuid` and `object_type`
in `i18n_translation`, maybe `object_field` is useful here too, letting us know
if it's used in `dashboard_title` or `dashboard_description` for instance. That
allows for more context in the translation app and more specific retrieval when
processing templated fields for retrieval
- building upon my previous command about the `context` field, maybe that's
not needed anymore with the 2-3 fields I identified above. Though it could be
nice to have an optional `extra_context` field too maybe to enrich the UX for
the translation tool, as in `{{ i18n("Translate this!",
extra_context="priority.p1") }}`
#### about garbage collection
Now if we have `object_uuid` and `object_type`, could even set up triggers
on-delete and clean up orphaned entries in the translation table.
#### about reuse
Now if all framework is strict about capturing `object_uuid` and
`object_type`, this means that multiple entries of the same string will have
multiple entries to be translated. My guess is the framework would tend to not
have a lot of duplicated instance of the same string, and that potentially you
may want to translate it differently in different contexts (?) Maybe the
translation app could offer a "propagate" feature, where it would look for
identical strings across `object_uuid`s and duplicate based on existing
translations.
--
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]
