Description
Under the last paragraph of the 'Hosting Setup' part of the wiki. in the second last sentence, the line features a missing space in "you cansetup the".

Reproduction
Steps to reproduce the behavior:

1. Go to https://github.com/smolespi/Hibiki/wiki/Hosting-Setup in web browser.
2. Navigate to the second last sentence in the last paragraph

Overview

In order to fix the infinite authentication issue, we introduced the noCache function to disable caching in each route. This fixed the issue, however, having things cached would be nice.

How?

We should try and find exactly why authentication (more specifically, reauthentication, etc) breaks if caching is enabled, and try and implement something more direct and less broad. This isn't a huge deal, but it could help save a teeny bit of bandwidth.

Perhaps implementing the old music commands would be something to explore? Use the Discogs & MusicBrainz API?

Localisation & Translations

Something I've been eyeing for a while is native localisation / language support.

Why?

I want the project to be universal. The first step to that was going completely open-source. The next step would be to break language barriers. There's also a large amount of foreign Hibiki users who's first language isn't English. Plus, it's another neat thing to show off.

How?

We'd need to make a way to read strings from locale files. I know @TTtie has experience in this - however preferably, we'd want to make it... clean and simple. Less of a total pain to implement. Maybe give me your input?

The actual translations would affect bot content. We'd translate every string sent by Hibiki. While this is tedious*, IMHO it's well worth it in the future.

Additionally, getting translators for core languages might not be too difficult. I know a few people outside the project who'd be happy to help, and our development team is pretty diverse language-wise (even though I only know English).

Thoughts? Suggestions? Possible implementation ideas?

Overview

Currently, in the Hibiki dashboard, we serve modules (Font Awesome, Bulma, etc.) from jsDelivr. However, a good way to have more control over this is to serve them from the webserver itself. This might increase speeds a bit, or might now - however it is more reliable. If jsDelivr breaks, then our app breaks.

Additionally, we should finally move away from jQuery and the couple of plugins that utilize it (I believe the multiselect thing uses it, maybe the emoji button does too). jQuery, while not as bad as most people make it out to be, is largely un-needed in 2020. We're targeting modern browsers (Firefox >= Quantum, Chrome >= 52(?)) so support for stuff such as IE10 is largely unneeded, and JavaScript in the web has gotten better and more consistent across browsers too. The only reason we really use jQuery still is, honestly, laziness and not having the time to either find better modules or make our own.

Finally, we should improve our Google Lighthouse score. While it's not too meaningful from a end-user standpoint, it's a) something to flex, and b) a good indicator on how our web app is. I think last I tried we got like a 75, and most of the problems was from Bulma being fat.

How?

Well, there's ways to serve stuff from node_modules and stuff. This is pretty easy, but it'd need a bit of testing. Additionally, we should generate our own Bulma stylesheets that are missing modules we won't need to save bandwidth. Finally, we should also optimize Font Awesome (there's a blog post out there on doing it) to save a lot of bandwidth as well. I'd love to use Fork Awesome, but it's lacking some nice icons and has some bugs with Bulma.

The Google Lighthouse thing is mostly just trial and error and good practices.

Description
h!catgirl invokes h!cat behavior. h!foxgirl invokes h!fox behavior. Slightly inconsistent (on a server, they happened to work correctly).

Reproduction

1. Use catgirl or foxgirl commands

Expected behavior
Expected catgirl or foxgirl. Got cat / fox.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Overview

Self-explanatory. Re-add proper dockerfiles that don't throw a bloody fit. I'm not very good with devops. Also, we have a docker util file to detect if we're running in docker.

Notes

Use the default port values in config.json for rethinkdb/dash/firewall/etc. User can edit them if they want to. PM2 is great and does it's job but TTtie made fun of me :'(

Also sorry for assigning you to so much stuff

Overview

Implement a simple, but powerful suite of audio playback commands (play, pause, skip, queue, search?)
This continues the original issue #1.

How?

There's a couple of good ways to go about this, but the two most popular ways are:

• Native ytdl-core streaming. Simple to write, native, but also somewhat slow and inefficient. Additionally, YouTube API keys can be pretty pricey.
• Lavalink. Lavalink is an audio sending service that's efficient, fast, but not native to the bot 100%. You still have to set up a JRE environment (very easy to do). However, I believe that the pros of using this outweigh the cons of not. As it streams audio without it directly sending to each shard, it saves a lot of bandwidth and stuff. Additionally, it's probably better than anything we can write. Additionally, there's some very (albeit pretty crap old code) work done on a scrapped v2.5.0 music project by @chiibiki that we can go off of.

Goals

Hopefully, we can get this functional. There are many TypeScript/JavaScript Lavalink drivers out there, and I've looked at a bunch of them. I'll finalize my selection soon and start work on it. I've pushed this to the v3.3.0 milestone.

Additionally, some nice features such as metadata retrieval could be neat. I'm not 100% sure how to go about this. Someone mentioned using the MusicBrainz API, and while possible, I've never done it before. We'll experiment around.