-
MSavoritias (fae,ve)
Me too
-
MattJ
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.
-
flow
thanks for working on this everyone :)
-
emus
> 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
-
emus
> 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
-
emus
> 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 :-/
-
emus
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.
-
Seve
Looks fantastic on mobile!
-
emus
stpeter, updated. maybe lets delete the old one
-
emus
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
-
Seve
Subscribed, will check!
-
emus
🙏
-
nicola
Great work @wurstsalat for the website
-
wurstsalat
thanks!
-
emus
We are soon finalizing our next newsletter release. Last late call to add your news: https://pad.nixnet.services/oHnY_ZvLT8SoFyCqIC2ung PRs prefered!
-
emus
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!
-
Nepptün
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.
-
MattJ
Yes, the protocol already supports language tags on MUCs and language tags on messages
-
MattJ
If you want translator plugins, clients would just have to implement that
-
Peter Waher
Technically, it would be possible to add a MUC extension that translates messages to desired language
-
Peter Waher
regardless of input language
-
Peter Waher
and do it on the server
-
Nepptün
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
-
Nepptün
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
-
MSavoritias (fae,ve)
Sounds like a great idea
-
MSavoritias (fae,ve)
For both the muc and messages
-
Nepptün
there is for example libretranslate .. it has a api
-
Peter Waher
choice of library would be implementation-specific
-
Nepptün
it works perfect, and it is fast like hell.
-
Nepptün
I offer 200 Euro as a donation for somebody who writes such a prosody module that uses the libretranslate api.
-
Nepptün
> 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
-
mdosch
You'd also need client support. Most clients just hardcore XML lang to en… 🙄
-
Nepptün
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
-
singpolyma
Should be based on UI language or system language I expect
-
mdosch
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.
-
Peter Waher
A good translator API would allow you to detect language (now if you’re going to use a languate translation API that is)
-
mdosch
It may use system language as default until you manually set avlanguage for that MUC.
-
Peter Waher
Annotation using xml:lang can be very misleading, as you’ve pointed out
-
Nepptün
I could imagine that the server does nothing until a client demands "translate to me in german" by setting up the xml:lang attribute
-
Peter Waher
you have 1 sender, and 1 receiver
-
Peter Waher
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
-
Peter Waher
Now, if you want that scenario to work, server needs to be able to identify language
-
Peter Waher
modern translation APIs support detection of language however
-
Nepptün
they have. libretranslate has language detection https://translate.zp1.net/?source=auto&target=de
-
Menel
Then it could be a compleatly client side feature without any changes to what servers and clients do currently
-
Menel
Sound like likely clients would be gajim or pidgin with their endless plugins
-
Nepptün
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.
-
Nepptün
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.
-
Nepptün
or on a phone ... some apis need api keys, and that is not DAU friendly. server solution is more elegant.
-
Nepptün
and if a client dont like the server translation nobody stop you to use a client solution.
-
moparisthebest
APIs are stupid and not privacy friendly, do it locally or not at all imho
-
moparisthebest
https://blog.mozilla.org/en/mozilla/local-translation-add-on-project-bergamot/ is just one example
-
Nepptün
yes true. its called a local api ..
-
Nepptün
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.
-
Nepptün
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.