May have found a ui bug, a paltry one albeit, regarding translations.
When I hover over the x or expander button I get en.babble.expand_chat and en.babble.close_chat. Also, I am assuming that the icons are not meant to disappear when hovering over them, cluding hovering over the hamburger menu for the chat; aesthetics. Just some ux stuff to ponder. Otherwise, a great plugin.
In my forum the chat plugin is not that heavily used.
I think it would encourage people to use it more if in the lower bottom of the browser window a tiny bar would say n users online whereas n= number of people with chat access are currently online (based on discourse online status)
Hmm it seems like discourse has changed the way they render their header on mobile slightly. Iāve put in a fix; let me know if that works for you. Iāve also fixed some oddness with the new post action dropdowns. Excelsior!
JanJoost:
I took some time yesterday and created a Dutch translation
Thanks for the contribution! Iāve pulled it into master and it should be available in the latest.
I know itās been about two months since you and @eatcodetravel were talking about collaborating on Babble upgrades. Did anything come out of that or will come out of it in the next few months?
As an update, Iāve been playing around with private messaging functionality in Babble over the past couple days. Hereās where Iām at at the moment:
Itās a more slack-inspired interface, with the ability to dynamically create messaging channels between individual users (and the plumbing is there for facebookās ādynamically creating chats with multiple peopleā functionality as well)
Iām also digging the āautomatically openā functionality, and am thinking about making it the default to open the sidebar chat to the channel list view by default on desktop (itād feel a lot more like a slack thing that way, and would be a pretty prominent piece of your forum). Admin toggleable, of course.
Sound notifications at the individual user level are still at the top of my list by far (discussed back in this thread).
I could come up with a bunch of other things, but I donāt know how much theyād overlap with your own personal goals for the plugin and requests from other Babble users. So Iāll refrain from giving you the full wishlist unless you say you want it all.
@gdpelican
Did some preliminary testing, and indeed it looks better. Mind you, I am an excellent picker of nits, so be warned
How I tested
New user with post count 0
New chat
Scenario 1:
Access chat via bull-horn (chat side-bar). Add messages, check post count on user statistics page.
Post count still 0.
Delete chat, create new chat.
Post count still 0 (and not a negative number) - this is good
Scenario 2:
Find chat via search function. Access chat via the ānormalā topic rendering. Add 5 messages, check post count on user statistics page.
Post count is now 5 (which is to be expected - weāre accessing the chat via the alternative rendering, so it behaves as a normal topic)
Delete chat, create new chat.
Post count still 5 (at least not deducted).
This to me is perfectly acceptable behaviour - at least we do not end up with negative post counts any more, for the enthusiastic chat users.
The icing on the cake would be to deduct the post count from the posts entered via the normal topic-rendering, but I imagine that would be (nearly) impossible to achieve.
But to keep the analogy alive: The cake is already delicious this way, and Iāll happily eat it. (The cake is no lie!)
The fix at the moment is a bit slapdash, essentially saying āskip over resetting user counts when you delete chatsā, which should be analogous to the āskip over resetting user counts when they make topics or posts in chatā.
Discourse is complicated software though, so Iām not 100% certain at the moment that the counts / triggers modified on creation are 100% parallel to those modified on deletion. However, if youāre happy, Iām happy, and will merge this after a little bit more smoke testing on my end.
Re: normal topic rendering, Iād rather get to a point where you canāt render chats as normal topics at all, rather than making them work as both. Thereās too much that can go wrong if we allow people to respond to chat topics with the normal Discourse flow, and vice versa.
That makes sense - would be good. I know from the user base I have here that they do like the idea of ālikingā a post though. But then again, itās a chat - they will just have to eat what we feed them! >: )
I (and others) have the ability to build that functionality (itās basically a port of the Retort plugin ), but likely not the functionality to make chats and Discourse topics 100% compatible.
I hadnāt even seen Retort but it looks fun! Thanks for the pointer!
As for the functionality: We can survive without it (and the users are already happy!), so thatās all good.
I also found out that most people use the topic-view of the chat because it works a bit better for them on mobile apparently. Iāll ask around what exactly it is that doesnāt work well for them in the normal chat-view, and will let you know.