Some translation messages allow the use of {submitter} (and other values), but for other translation messages this context is not provided,
so maybe it would also be a good idea to document what context is globally available and what context is available for other translations.
Maybe adding what context is available to the language key would be a good idea (e.g. grouping all translation messages that have the same context).
Also moving any strings from queue.js into index.js would be a good idea, changing the functions of the queue to return enum variants instead of message replies.
The
i18nlibrary could be used to translate bot response messages. This will allow the bot to be translated into other languages more easily, as well as also customizing response messages more easily. I have this very old branch of this feature here: https://github.com/liquidnya/fluid-queso-queue/tree/feature-translation The English language file in that branch looks like this: https://github.com/liquidnya/fluid-queso-queue/blob/feature-translation/locales/en.json I think re-implementing this feature might be easier than merging this branch.Some translation messages allow the use of
{submitter}(and other values), but for other translation messages this context is not provided, so maybe it would also be a good idea to document what context is globally available and what context is available for other translations. Maybe adding what context is available to the language key would be a good idea (e.g. grouping all translation messages that have the same context).Also moving any strings from
queue.jsintoindex.jswould be a good idea, changing the functions of the queue to return enum variants instead of message replies.