Comment on

• jupiter_rowland@hub.netzgemeinde.eu ⁨10⁩ ⁨months⁩ ago

  @maegul @Jeff Sikes @Kainoa @Chris Trottier This would have to happen on the server side. And this, in turn, would work the best if it happened directly on the instance servers, and if it was part of the #Fediverse projects themselves.
  
  We've seen what happens when you rely on a third party. It tends to lean towards something centralised, either because someone deliberately only designs a centralised service for it, e.g. #Mastodon full-text search, or because nobody but the devs can be bothered to run an instance, e.g. #Guppe.
  
  Also, decentralised third-party services will have to be connected to Fediverse instances by the admins manually because the admins will have to decide which instance to connect. Many admins won't take that step at all because they've stopped reading the manual the very moment their instance started working reasonably well, and so they don't even know that they have to connect to such a service.
  
  That said, the Fediverse already speaks one common formatting language, and that's #RichText. #CalcKey translates the #Markdown in out-going messages to Rich Text. #Hubzilla translates the #BBcode in out-going messages to Rich Text. #Streams translates Markdown, BBcode and #HTML to Rich Text. And so forth.
  
  Also, translation between message formats will remain half-useless as long as certain projects show a severe lack of capabilities of displaying messages, and this won't change anytime soon, if ever.
  
  Like it or not, #Mastodon fans, but Mastodon is the worst offender. It can't have more than four images in one post, and it can't embed images within the text. All stuff that has been possible on projects older than Mastodon even before there was Mastodon.
  
  On #Hubzilla (and not only there, but just to take one example), I can design any regular message like a blog post:
  

  Text block 1
  Image 1
  Text block 2
  Image 2
  Text block 3
  Image 3
  Text block 4
  Image 4
  Text block 5
  Image 5
  Text block 6
  Image 6
  Text block 7
  Image 7
  Text block 8
  Image 8
  Text block 9

  
  This is perfectly normal. And this is perfectly legit. #Friendica, Hubzilla and #Streams were deliberately designed to make this possible. And while Hubzilla has an optional extra functionality for long-form articles, Friendica and (streams) only have this one way of long-form posting. So, again, this is normal and legit and intentional.
  
  On Mastodon, however, the very same post looks like this:
  

  Text block 1
  
  Text block 2
  
  Text block 3
  
  Text block 4
  
  Text block 5
  
  Text block 6
  
  Text block 7
  
  Text block 8
  
  Text block 9
  Image 8 | Image 7
  Image 6 | Image 5

  
  The images are ripped out of their context, reversed in their order, and only four even make it into what Mastodon displays.
  
  The only thing a "translator" could possibly do here is put the images in the correct order. Still, only four would make it onto Mastodon timelines due to Mastodon's limitations, only that it'll be the first four instead of the last four. And also due to Mastodon's limitations, they will still end up after the end of the post instead of embedded between text blocks where they belong.
  
  In the opposite direction, from Mastodon to Hubzilla, a "translator" could be a bit more useful. Currently, when a Mastodon toot with multiple images appears on Hubzilla, the images are put ahead of the text and in reverse order. What the "translator" could do (unless Hubzilla introduces that first) is embed the images at the end of the post in "reverse reverse" order. I'd suggest to also resize them (non-destructively; Hubzilla does that by default with its own images) so that four of them can be shown in a 2x2 arrangement just like on Mastodon, but on Hubzilla, that would cost them the alt-text.

  source

  • maegul@calckey.social ⁨10⁩ ⁨months⁩ ago

    @jupiter_rowland@hub.netzgemeinde.eu server side yes, but developed apart from the platforms and optionally included on either a platform or instance basis.
    
    I’m invoking pandoc as a model because they take pride in supporting as many formats as possible and have adopted an all-to-all design that reduces all formats to a single common abstract spec.

    source

    • jupiter_rowland@hub.netzgemeinde.eu ⁨10⁩ ⁨months⁩ ago

      @maegul So instead of another full-blown Web application running on a Web server next to one or multiple Fediverse project instances, this could theoretically be covered by a library plugin for something that runs on the Web server anyway. Same way as tying e.g. ImageMagick or various SQL databases into Web applications. PHP comes to mind, but then there'd also have to be one for Ruby-on-Rails.

      source