Translation propagation/distribution

[nijel]

Is your feature request related to a problem? Please describe.
Currently, translation propagation is configured per component and affects components within project. In some cases it does not work well:

• for private instances propagation across projects might be needed (LibreOffice)
• the component settings is probably not the place people would look for this setting

Describe the solution you'd like
Proposals welcome. It could be done by addon, but I'm not sure it's a good approach here.

[comradekingu]

I think it is extremely valuable to be able to trace back a translation. Launchpad has this, where it lists the project name a string came from. That way one can correct errors at its root. The user could be Autotranslation-originalusername. That way it is possible to gauge urgency of review.

The problem with just doing "autotranslation" from unknown origin is that bad ideas propagate too, and it makes it easier to hide malice.

[nijel]

While I agree with you, it's not the topic here - the translation propagation is by default enabled on project level and all changes are credited to current user.

PS: See #3009 for more related issue.

[comradekingu]

OK, commented there instead. I think it would be valuable to only have suggestions by default, and also make it possible to cherry-pick what translation components one wants to take strings from.
Right now I think OpenWRT duplicates a lot of strings from Turris.

[nijel]

Still there are two distinct features:

Translation propagation happens inside project (unless disabled) when somebody is translating. Such changes are done on all components within project and their authorship is correct.

Automatic translation happens either manually or by addon (when component is updated) and in this case the authorship is not there also the source is not tracked anywhere.

[nijel]

Anyway back to original topic - the translation propagation needs better configuration. With #4284 on way, this probably needs to be at component level.

Possible approaches:

• Configure at component level from where it can get updates - this is most flexible as it allows one way propagation, but would need to configure all components in a project to share a translation to get replacement of current setup.
• Move the propagation to an addon. This is probably the most obvious place to look for this kind of thing, but still that would need a way to select components and that would be most likely the one way propagation as described above.
• Create "Propagate group" of components that will propagate the translation.
• Reuse component lists for this (the good thing is that there is already automation and API for managing these). Having additional option there to say "This component list propagates translations" might be a way to go. On the other side, this would produce quite some component lists and would require ability to manage this by project admins (right not the component lists are manageable only by site admins).

Any of the approaches will need additional logic to deal with discovery created components as that currently copies the flag from the master component and it should be still honored.

[comradekingu]

Isn't translation propagation a solution to "dialect"-languages too?
Launchpad always had the original string listed, and that is the best implementation I have seen.

[nijel]

The dialect languages AFAIK works only in Gettext and most likely not in all implementation of that (I think that https://github.com/phpmyadmin/motranslator/ loads just single file and does no fallback).

[UncleSamSwiss]

It would also be great if the propagation of a single text could be prevented by adding a translation flag to that text.

Explanation: we have many components inside a project (up to 400) and you don't want to translate the English "Type" with the same texts for German for example (once it is "Typ", once it's "Art", and so on). Disabling propagation completely is out of question as it helps us a lot to get the same "language" everywhere; but in this rare case, it would be nice to disable it.

[KadAnna]

Allow translation propagation propagates not only texts, but also statuses - which I think is wrong. In the same project, but different repos, I have strings Unknown=Neznámý, but also Unknown=Neznámá. When I had the option Allow translation propagation on, a change in one repo triggered change and status Waiting for review in the other repo as well - that is fine. But when I approved the translation in the first repo, this string was also approved in the other repo, which I found wrong. It does not follow the logic - a change in string needs to be reviewed (and I have this workflow, as seen in the pic).
Particularly in this case, I may want Neznámá in one occurance but Neznámý on the other. With this status being forced, I am not allowed to have this difference.

[nijel]

Presently, the primary use case here is using in nearly same context - for example, translating Android and iOS applications. In that case, sharing the state is okay.

For a more general use case, this probably needs to be a bit more fine-grained - currently both status and texts are propagated. With status only changes, it might be more tricky - what should happen in case strings are marked as needing editing? Should it affect all strings, or only a single one?

[nijel]

Another related topic is handling strings with same source, but different context/key, see #8295.

[matzeeable]

Is there a timeline for this feature request? We are running into a similar issue in our production Weblate instance as there are inconsistent strings across projects.

[nijel]

@matzeeable I don't think we've come to a conclusion on how to approach this issue yet, so there can't be a timeline.

[cloph]

FYI: for LibreOffice we modify the same function (trans/models/unit.py) to not filter on the project_id being the same, but instead on the component name. Our usecase is having different projects representing different branches, all having the same components (and qualifying strings still share same source and context), so that simple change covers our specific setup/project & component structure (and overall translation workflow wrt branches)

[nijel]

Revisiting #3166 (comment) after years and I can now see two viable approaches:

Component lists

This is an existing feature which is not widely used as it is admin-only right now. See https://docs.weblate.org/en/latest/admin/componentlists.html

It would need several improvements to the component lists (for example, #1370).

Add-ons

With #10052 and #10051 on our road map it makes it possible to use add-on in site-wide scope.

What remains to be figured out is the approach for configuring this. How about using existing template markup to define propagation groups?

• Project scoped propagation (current behavior): {{ project_slug }}
• LibreOffice propagation: {{ component_slug }}
• Anything more complex is possible as well: {% if component_slug == "special" %}second{% else %}first{% endif %}
• When template would evaluate to a blank string, propagation would be skipped

What do you find a better approach? Is it better to review a hidden and barely used feature for this or use add-ons?