search

WeblateOrg / weblate

Web based localization tool with tight version control integration.
https://weblate.org/
GNU General Public License v3.0
4.57k stars 1.01k forks source link

Federated translation memory #3749

Open nijel opened 4 years ago

nijel commented 4 years ago

Is your feature request related to a problem? Please describe. It might be interesting to share translation memory between instances. For example Fedora and openSUSE might be interested in this, but it's more generic topic.

Describe the solution you'd like The design is still unclear:

github-actions[bot] commented 4 years ago

This issue has been put aside. Currently, it is unclear whether it will be ever implemented as it seems to cover too narrow use case or doesn't seem to fit into Weblate. Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

comradekingu commented 4 years ago

Would need to revisit 6.3 in https://hosted.weblate.org/legal/terms/

Should the Project opt in for the Translation Memory, license to use the translation is granted to all Translation Memory users.

It isn't obvious to me who "users" are, nor what "use" entails. Does it ever expire, under any conditions?

agateblue commented 4 years ago

So I've been pinged by @Jibec, as I'm a (happy) weblate user, and also happen to work on Funkwhale, a federated audio streaming software, that uses ActivityPub.

As far as I understand, the initial feature request is about building a shared translation memory that can be reused accross Weblate instances. Please correct me if I'm wrong.

In the scope of this feature, I would rather strongly advocate against using ActivityPub as the federation protocol. There are two main reasons for this:

  1. ActivityPub in itself is rather complex to implement properly (in particular HTTP signatures and JSON-LD)
  2. I don't think the benefits of it's complexity are actually required to implement the requested feature.

As far as I can tell, if the need is only to have access to other Weblate instances translation memory, this can be rather easily supported by an ad-hoc API endpoint and regular pull. For instance, if we consider it needs to be implemented at the instance level (it could be implemented at the project level maybe?):

Sure, in theory, with ActivityPub, you could have real-time updates (translator from weblate A translate something, weblate B is notified immediatly). But the increase in complexity isn't worth it IMHO.

comradekingu commented 4 years ago

False meritocracy is secondary to the real level of trust; that of being able to vet and change strings. The issue is very prominent on Transifex, where by blind faith, even deleted entries are added to TM, and hard to navigate to. Thus, bad translations spread from there, and it is feasibly impossible to prevent it. There are failed checks on Hosted Weblate that nobody can fix without giving up what makes it viable.

In place of easy access, some Weblate instances have egregious CLAs, and CoCs that contributors are expected and sometimes required to champion. Either for string contributions, or upstream string/code contributions. To take part, there should be no such additional requirements.

With artificial barriers of entry, quality goes down as a result. In similar vein to sharing TM and platforms with closed source software, it is something nobody asked for, it placates to the few on the backs of the many, in a way that tarnishes the product and reputation of the libre software community. Federation means federation.

As such, Pootle, Translatewiki and some others should be able to join. Launchpad has a good system, where one can see all places a string is in use. Unfortunately they have license requirements on strings entering their pool. Locked components should also never be in the pool. There should be as many opportunities to tear down as to accumulate TM. Right now the TM system is nowhere near resilient enough. Anyone can upload as much as they want, multiple times.