Would this be helpful to leverage?

As suggested by one Pro user, a more minimally viable solution would be to include a "Reply-To" header with an email that the author chooses. If they fill out this field, replies will go there; otherwise they'll go nowhere as they do today. I think we'll go that route first.

Working on this now. Some implementation details thus far:

Dropping for future reference, in case you ever want to drop PHP dependencies 😀

• https://plausible.io/
• https://usefathom.com/

Docs are updated and WF pull request is open: #436.

This is already supported on Write.as and the Go API library, added in the attached commits. Will add it to WriteFreely and our API docs next.

Is Write.as served by Nginx, Apache, or something like that? I noticed that testmysite.io reports that HTTP2 is not enabled, but should be a one-line fix in Nginx config or there's the more bleeding-edge approach https://h2o.examp1e.net/ 😉

Ah cool no worries. Yes Project Fluent is great, we've started using it where I work. It addresses the shortcomings of GNU Gettext (you can actually have variations of the same translation when different languages don't have a one-to-one conversion for some phrases) and Mozilla has also created a nice web app to collaborate on translations: https://github.com/mozilla/pontoon/

So far, unfortunately we've only localized reader-facing UI elements (email subscription form, "Read more" links, etc.). Would definitely like to localize the editing UI as well in the future! Thanks for sharing that tool, I haven't heard of it.

Is the write.as web UI available in other languages (maybe through https://projectfluent.org/)? It isn't an short-term need, but may be nice to have some day for editors who's first language is Spanish. I didn't see a setting in my account preferences, but maybe it's somewhere else

No this task actually refers to more granular permissions just for Write.as (versus Submit.as).

Does the lack of this mean that all users of Write.as Teams are effectively admins? Not a blocker, just checking

Awesome, that sounds easy enough then. Thank you!

There will be a toolbar button in the WYSIWYG editor to add an image, which will let editors paste in the Snap.as image URL. We may need to make this easier, like by just showing the image URL in Snap.as instead of the full Markdown. Will investigate that.

iOS app was released on October 20, 2020.

We should provide a dedicated space for editing navigation items.

No problem, we can teach editors to adapt in the meantime! Combined with T520, will there at least be a way to copy image embeds from Snap.as into the WYSIWYG editor without having to copy markdown and switch to markdown mode (assuming that will still be an option)?

@heyakyra In the short term, unfortunately uploads still happen in a separate place (Snap.as). But we'll work toward adding uploads into this editor!

@heyakyra This is addressed in T812. Basically, that'll be possible with a new custom template system.