XSF Discussion - 2023-03-30

Me too

Hi folk, update from iteam: The mail/DNS server is still down, and we've confirmed it's due to a hardware failure and not simply network issues. DNS should be working fine served from our secondary DNS servers (thanks intosi!). The mailing lists will be down for a while longer as we work on setting up a new server and restoring backups. We'll keep everyone posted.

thanks for working on this everyone :)

> Peter Waher: > 2023-03-29 06:07 (GMT+02:00) > In May of 2014 (soon 9 years ago) I made a study of the differences (strengths/weaknesses) between XMPP and MQTT, and tried to create interest to improve XMPP with extensions of things lacking in XMPP, but that existed in MQTT. (This includes Quality of Service and queue-ing, for instance, but also other adjacent areas. Let me know if anyone is interested in reading results.) Interest was low from the XSF group, which focused(-s) mainly on IM, rather than viewing XMPP as a more generic transport protocol for multiple use cases (other than IM). (Interest is/was higher in other groups, who wish to stay more agnostic to overlying use cases). feel free to add it to the pad i shared recentlt

> pep.: > 2023-03-29 06:09 (GMT+02:00) > That's what I've always found sad about the XSF :( I share this to the level that folks could / should work& agree on certain general targets

> stpeter: > 2023-03-29 08:49 (GMT+02:00) > @emus I’ve created https://wiki.xmpp.org/web/Board-Meeting-2023-04-05 - you and others should feel free to edit it. peter, there was one created by me already with XX as dates :-/

Many thanks again to wurstsalat getting us a decent overview of the structure: https://xmpp.org/about/xmpp-standards-foundation/ I would recommend to ask everyone to review their role and step back if they have no contributions. it does not make sense to list "stale" persons. we should rather advertise to find others helping then.

Looks fantastic on mobile!

stpeter, updated. maybe lets delete the old one

Seve: 🍭 its based on the effort I started here a while ago: https://github.com/xsf/xmpp.org/issues/920 if you have more suggestions listing let us know via an issue

Subscribed, will check!

🙏

Great work @wurstsalat for the website

thanks!

We are soon finalizing our next newsletter release. Last late call to add your news: https://pad.nixnet.services/oHnY_ZvLT8SoFyCqIC2ung PRs prefered!

Another thing I wasn't sure if announced really: https://xmpp.org/software/software-comparison/ one can cross-compare the clients, servers etc doaps now and thanks again to wurstsalat!

Hi compadres, I have a idea, and I want to with you about it. A lot of rooms (mucs) use other languages then English, and the xmpp stanzas have a part like "xml:lang" could we place in there the language of the muc and/or to make a possibility that a user who want to talk in a different language in the muc to setup his language. This could open the door for translator implementations when in a room somebody not speaking the language of the room could use a translator plugin.

Yes, the protocol already supports language tags on MUCs and language tags on messages

If you want translator plugins, clients would just have to implement that

Technically, it would be possible to add a MUC extension that translates messages to desired language

regardless of input language

and do it on the server

Peter Waher, that is exactly what I want and to make it more easy, the clients could trasmit in the xml:lang attribute the language they are talking in

for example I am german, I enter a english room with translation, I could settup my xml:lang="de" so all I write will be translated to english to the room and the server translates me all messages to german

Sounds like a great idea

For both the muc and messages

there is for example libretranslate .. it has a api

choice of library would be implementation-specific

it works perfect, and it is fast like hell.

I offer 200 Euro as a donation for somebody who writes such a prosody module that uses the libretranslate api.

> regardless of input language it must not be regardless, it should only translate for the user who have setup another language then the official room language in their message stanzas. But I think it can be configuration issue if everything or just foreign languages

You'd also need client support. Most clients just hardcore XML lang to en… 🙄

yes it would be super comfortable to have a select button near the input to select the language the server should translate the messages to you

Should be based on UI language or system language I expect

Not really, I have my system set to German, but I'd prefer to write in english for english MUCs rather than using a translator.

A good translator API would allow you to detect language (now if you’re going to use a languate translation API that is)

It may use system language as default until you manually set avlanguage for that MUC.

Annotation using xml:lang can be very misleading, as you’ve pointed out

I could imagine that the server does nothing until a client demands "translate to me in german" by setting up the xml:lang attribute

you have 1 sender, and 1 receiver

you might want (as a receiver) to get translated text. But the sender might be completely unaware of all these features, and might also have xml:lang set to en by default

Now, if you want that scenario to work, server needs to be able to identify language

modern translation APIs support detection of language however

they have. libretranslate has language detection https://translate.zp1.net/?source=auto&target=de

Then it could be a compleatly client side feature without any changes to what servers and clients do currently

Sound like likely clients would be gajim or pidgin with their endless plugins

sure it could be, but i think that as a server module it would have a certain elegance and servitude. you write in your language, we take care.

the other aspect is that as a server module it would be the work done only once. and client side there are some strange clients like the thunderbird client who don't support plugins.

or on a phone ... some apis need api keys, and that is not DAU friendly. server solution is more elegant.

and if a client dont like the server translation nobody stop you to use a client solution.

APIs are stupid and not privacy friendly, do it locally or not at all imho

https://blog.mozilla.org/en/mozilla/local-translation-add-on-project-bergamot/ is just one example

yes true. its called a local api ..

it is very easy to install libretranslate locally next to the server and then you can let them communicate on localhost or on socket. and libretranslte is a offline translator.

As i said i am not rich, but i would donate 200 buks to the one or to the group that writes such a module.