Language filter or automated translations

A Podmin might decide this: "enable_translation_for: " all | public | private | none
And podmin must mention it in its terms&conditins.

As developers we could create a template for this, if its ever be a PR and merged into dev.
I would not make a big ceremony about this, and commit this feature because of this.

What about: let podmin decide this and leave a mention in the description in the config file?

This is something we should design for diaspora* the network, not whatever particular installation with particular terms and services someone has.

I don’t think we can claim a reasonable expectation of privacy being part of the network and then make it super easy for an individual podmin of your contacts to send the private data you shared with specific contacts to a third party service.

Making these things configuration to just claim “oh the podmins decide this” is too much of a slippery slope for me.

So, how to get this done:
Reject this feature?

As this is open source every podmin can do with its pod whatever he/she likes to do. I have seen Pods with a monthly subscription fee out there.
So, why not let improve the network for a often requested feature? On Sign-In every user has to accepts Terms&Conditions.
Making it “Part” of the diaspora network, this function may be part of some kind of global terms and permissions.

I understand that this should be considered. but on the other hand discussion on this went for nearly 10 years without any outcome.
Time to act.

Yes, every admin can change the open source code in whatever way they want.

But we as a project endorsing and making it easy to send private user data to a third party service is wholly different message. Let’s not compare apples and oranges here.

How to get something done that so far has seen no or only poor implementation suggestions that preserve or further the projects ideology and vision?

Implementing a feature just because it’s easy to do so is a poor reason to do it, on multiple levels.

1 Like

I see these privacy concerns, but isn’t the Deepl T&C compatible with these needs?
https://www.deepl.com/pro-faq.html (Read ‘Datenschutz’ in the FAQ)

Data is not stored and immediately deleted.

What needs Diaspora* as a network to get this done?