jdev - 2024-03-09


  1. MSavoritias (fae,ve)

    > > Most people write messages in both languages, now you gotta flip a toggle each time? That's insanity > moparisthebest, looks like you're missing imagination for a UI, that's about it :) > Your client can display the only available language and tell you at the same time which language it is. Also it could even propose to translate it to your language if necessary, which is harder for a client to propose automatically if the message isn't known to be in a different language yeah that sounds like what i was thinking. combination of translation xep with xml:lang used everywhere

  2. MSavoritias (fae,ve)

    and you can toggle which languages to show so mods for example can see all languages or people who want to learn languages can also see multiple languages

  3. MSavoritias (fae,ve)

    and when you reply to a message it automatically changes the language to match the message replied to. with a manual pick language toggle

  4. MSavoritias (fae,ve)

    and being able to have seperate fields synopsis-description and mulpltiple languages helps not to overcrowd the UI where you have to scroll endlessly of room descriptions in mutliple languages

  5. pulkomandy

    Even for users, at least for me it's not uncommon to write messages in both french and english, say on mastodon or linkedin. Maybe not on chats (it would be annoying to write everything twice), but that's not the only thing xmpp does

  6. MSavoritias (fae,ve)

    yeah for sure. expecting a person to write a message multiple times to match the languages in a room is unworkable from the start. it will never happen

  7. MSavoritias (fae,ve)

    something like the small model firefox has would help to translate here, but i am very skeptical of actually adding such a thing to my app. any kind of "model" will have a lot of errors and people's expectation would be to communicate real-time with languages they don't know which will end up in a horrible experience

  8. pulkomandy

    if you do automatic translation, it should be done at the receiâer's end, not at the sender's

  9. pulkomandy

    But such things exist. There are people chatting through translation systems with other people they don't have a language in common

  10. pulkomandy

    There are people using screenreaders, that benefit from knowing which language the text is in as well

  11. MSavoritias (fae,ve)

    agreed

  12. pulkomandy

    And for messages in multiple languages at the same time, it won't happen all the time, but there are some useful cases: bots, maybe sending a "server announcement" to all users on your server for a maintenance operation

  13. pulkomandy

    Sure, it's a lot less common

  14. MSavoritias (fae,ve)

    if the translation is done on the recievers end you won't run into the "big stanza" problem anyways. because its only one language that is sent

  15. MSavoritias (fae,ve)

    and with stuff like the fluent translation framework there is no source language to begin with. so its a lot more inclusive

  16. lovetox

    about https://xmpp.org/extensions/xep-0446.html

  17. lovetox

    why not send a thumbnail directly in the message?

  18. lovetox

    is it to big? how would this work with http sources?

  19. lovetox

    ah ok, its called jingle content thumbnails, but it can have a http url

  20. lovetox

    but i cannot download it without user interaction anyway because of privacy concerns, and if the user interacts i can download the whole thing and create my own thumbnail

  21. lovetox

    i think i remember this was discussed before and the conclusion was its better to send the thumbnail with the message, instead of giving a source to download it from

  22. singpolyma

    If its small enough it could be a data uri. Or could use another safe source like Bob or jingle ibb

  23. lovetox

    also there was once talk about blur hash, did anyone use this?

  24. Zash

    Someone (larma?) had some idea about sending a part of a PNG image, where the other parts are static which was said to be better than blurhash

  25. Link Mauve

    I’ve also experimented with a single block of BC7 and the quality was similar while much smaller to transport, with the added benefit that it can be used by desktop GPUs without CPU decoding.

  26. Link Mauve

    ASTC would also be useful to experiment with, especially because its block size can range from 4×4 to 12×12 (for the same amount of data: 16 bytes).

  27. Zash

    blurhash seems like a non-standard awkward thing so I would prefer something simpler. also base85 or whatever‽

  28. Zash

    blurhash seems like a non-standard awkward thing so I would prefer something simpler. also blurhash uses base85 or something ... that I don't have an implementation for‽

  29. Link Mauve

    Right, while PNG, BC7 and ASTC are proper standards.

  30. larma

    blurhash also easily leads to very weirdly wrong images

  31. Link Mauve

    I hate the rift between desktop and mobile supported formats though, only Intel supported both for a short while. :(

  32. singpolyma

    > also there was once talk about blur hash, did anyone use this? Yes i support both blurhash and thumbhash

  33. lovetox

    in what way support? when/where do i need to send this? are you saying you send a blurhash as data uri in the <thumbnail> tag?

  34. larma

    https://larma.de:5281/file_share/Z8VWgzOGj7LkKAfonrsOzI8K/mountain.jpg

  35. larma

    ^ That's an example of an image where blurhash fails terribly

  36. larma

    https://larma.de:5281/file_share/57XTY5ZdmkCk3_fmcUZg2-IV/Screenshot%20from%202024-03-09%2019-42-06.png

  37. larma

    It's generally pretty bad if you have high contrast pictures where there are large light and large dark regions

  38. wgreenhouse

    only take pictures of rugs

  39. larma

    also blurhash doesn't have any alpha support, which I personally think is very important for this feature: If the original image has alpha, you have to do something with that alpha. As we have a diverse client scape, we must expect a high variation of backgrounds

  40. larma

    thumbhash is way more decent than blurhash (better colors, supports optional alpha) and needs less bytes than blurhash (or similar amount when using standard base64 encoding vs blurhash custom base83). However it has even less implementations and is less widely used

  41. singpolyma

    > in what way support? when/where do i need to send this? are you saying you send a blurhash as data uri in the <thumbnail> tag? lovetox: as thumbnail in sims yes

  42. singpolyma

    I use image/blurhash and image/thumbhash which obviously ideally would get registered

  43. lovetox

    ok the implementation is 250 lines of javascript, i think i can port this to python

  44. lovetox

    oh no someone else did this of course already

  45. Zash

    so I take it we've decided on blurhash then? :(

  46. singpolyma

    I prefer thumbhash but I support both

  47. lovetox

    i think i will go with thumbhash if larma thinks its better suited

  48. singpolyma

    Its also a binary format instead of an ascii one which means we can encode it however we like more easily

  49. larma

    Quality and features of thumbhash are better, so I'd definitely suggest to go with that rather than blurhash. However I think that just going with a very small bitmap might be reasonable as well

  50. singpolyma

    "potato jpeg" is usually in the comparison charts

  51. larma

    Binary portable pixmap would be suitable for example

  52. larma

    A 4x2 24-bit ppm P6 should be 35 bytes

  53. Link Mauve

    Thanks to this discussion, I found a bug in LLVM. ^^'

  54. debacle

    Pardon for coming back to `xml:lang`. I assume, that having a language indication on the protocol level might be helpful for screenreading software, i.e. for accessibility.

  55. jonas’

    those {thumb,blur}hash things typically look much better than an upscaled 4x2 24-bit ppm for instane

  56. jonas’

    those {thumb,blur}hash things typically look much better than an upscaled 4x2 24-bit ppm for instance

  57. wgreenhouse

    debacle: and what language the server sends for error responses, etc.

  58. larma

    jonas’: I strongly disagree (assuming you obviously put an appropriate blur on top after scaling up), but I guess that's a little subjective

  59. Zash

    How about emojihash? Use 𝑨𝑰 to match the picture to some emoji and then scale that up! Stuff like 🌅️ or 🦆️

  60. MattJ

    Zash: that's so terrible but great I expect to hear Telegram is doing it next month

  61. MattJ

    If the sending app could indeed determine what type of picture it is (at least in some simple categories like portrait, landscape, cat, ...) and show an appropriate emoji as a placeholder that would be pretty nice

  62. wgreenhouse

    Cat.

  63. Zash

    portrait, landscape, cat, bird. that about covers 90% of it I imagine :D

  64. wgreenhouse

    the bird-crazed sighthound in my pfp agrees.