bridge

patcon 2021-03-29 21:26:47

The Mattermost plugin seems neat btw!

Unlike most translation tools I've seen, it _seems_ to translate messages for everyone when one person requests it, which feels important to create a consensus reality where everyone knows what everyone knows. Every tool I tested didn't do this -- they'd just translate per-user client-side, usually when someone clicked a hidden menu. And so it was an isolating experience where a foreign speaker who knew about the feature could technically read, but they knew most speakers didn't know about it, and they couldn't know what other foreign speakers were seeing

Just some odd dynamics there, that work against foreign participation

patcon 2021-03-29 03:37:49

Had doubts about this, as not sure how full-featured tengo script is, but seems it might be possible: https://github.com/d5/tengo/issues/107

patcon 2021-03-29 21:39:16

Interesting. I appreciate unix philosophy, but I guess I had opposite sensibility here: unix philosophy struck me as favouring the most low-level decomposable tool, which I thought would be translating in the service-agnostic bridge tool.

patcon 2021-03-29 21:39:32

Plus, I'm a little biased in that Code for All was interested in translation in their Slack, and I was eager to support that. I'm also not in any communities that use Mattermost, and so if the solution is a Mattermost plugin, this becomes an initiative that my other community spaces have no stake in 🤷🏻

patcon 2021-03-29 21:39:51

Which is perfectly ok, to be clear -- this has momentum of its own and I don't necessarily need to be a part of it :)

patcon 2021-03-29 21:42:37

Also, just realized something: were you thinking that translated messages in Mattermost would get passed through the bridge to other places?

pm5 2021-03-31 08:55:48

Well, mattermost has a few advantages to the bigger view of communication. Slack is hard to scale in terms of secondary features like message history, limits of number of apps installed, etc. And building an infrastructure for alternatives is one of my motivations of working on a stable bridge service. We have also been criticized in the past of supporting proprietary solutions instead of open source, community-owned solutions. But that is entirely another topic.

pm5 2021-03-31 09:00:41

So I think there is clearly different views here of the scope of the project. As I said, I will mostly focus on maintenance and monitoring of the bridge as my priority, so for translation, I'm totally fine if someone implements it in its own approach first. Those things above were just for sharing some thoughts of how I would approach it if I'm doing it now. They may change (quickly) over time, too. (Tengo looks nice)

pm5 2021-03-31 09:12:44

It's mainly if matterbridge can support the kind of extension we have in vision. I would hope we can have users setting up their own bridges across communities, with consents from both sides, and people from both sides would be actively reminded of these connections. I would hope we can provide these features with bot commands/dialogues because it seems more friendly to the users. It doesn't seem feasible to pack all these things into matterbridge, so there needs to be some way of connecting the bridge to a bot program. If matterbridge is currently only focusing on bridging two ends with limited ability to translate the messages, then one of the ends could be a place to inject a bot program. So a separated center of exchange for messages comes up into the picture. Mattermost just might be a clear choice for it nowadays because of the limitations of slack.

pm5 2021-03-31 09:17:42

Again, all of these do not have to be in the scope of a translation bridge. And we are still in POC stage anyway so none of these needs are justified even the slightest.

pm5 2021-03-31 09:18:28

👆 (me throwing out ideas) 🤟

patcon 2021-03-31 13:37:50

> It doesn’t seem feasible to pack all these things into matterbridge
Totally. I appreciate your thoughts and ideas @pm5 :)))

patcon 2021-03-31 13:39:50

I think the angle I took before was that the really custom “management” stuff is something else that just “builds” the toml matterbridge config. that’s where all the magic logic is (consent, interactions, config, etc). If matterbridge can read a remote config file, then only a small bit of basic translation logic need go into matterbridge itself. the rest of the cleverness is another app that manages the config (and maybe creates nice UIs around that)

patcon 2021-03-31 14:00:11

I’m aspiring to stay open to the idea of using data from a plugin! 🙂 i just have this prickly pessimism from what i recall of the event-driven model of core matterbridge, which makes me feel it could be quite messy…!

patcon 2021-03-31 14:02:11

pessimism is not a good place to stand! but i’m just acknowledging it to be candid 🙌🏻