chore: Improve getNearestCommands

[carafelix]

• closes #18
• closes #16
• encapsulate return value for getNearestCommands to prefix+name

Pending:

• [x] Runtime check for ctx.from.language_code (IETF > iso-639), would benefit from https://github.com/grammyjs/types/pull/45/
• [ ] add scope into the fuzzy match filter

[carafelix]

I think, since we are doing it for langs, filtering could also consider the update scope. Once I refactor the toElementals function, I can add that if appears proper

[roziscoding]

I think, since we are doing it for langs, the filtering could also be applied to the update scope. Once I refactor the toElementals function, I can add that if appears proper

I don't really get what you mean by applying the update scope. Could you give me more details, please? 😅

[carafelix]

what you mean by applying the update scope?

Sorry I didn't express myself correctly. I edited for clarity, but: In this case, the update = the incoming message. Update scope = ctx.chat.type + other properties adhering to the BotCommandScope type

As of rn, getNearestCommandcalls fuzzyMatch using ctx.from.language_code for filtering / prefer command names from the user lang. The same idea could be used with ctx.chat.type (and in a more complete case, plus the admin / member stuff) to filter leveraging the BotCommandScope cases.

TLDR: example: if a message is coming from an admin in a group chat, that would be BotCommandScopeChatAdministrators scope, etc

[carafelix]

Potential addition: Encapsulating the logic for unhandled ::bot_command, using getNearestCommand, into a localizable middleware that can be easily install like:

// at the end of your command handling installs
const my404 = commandNotFound(
        [userCommands, adminCommands],
        {
            found: 'blabla command found is $COMMAND',
            notFound: 'sorry not found any command like $INPUT'
        }
    ).localize('es',
        {
            found: 'papito tu comando es $COMMAND',
            notFound: 'papi no encontre nada parecido a $INPUT'
        }
    )
bot.use(
    my404
)

Might not be necessary since similar terms can be archive using the i18n plugin + getNearestCommand. And a doc example could be enough

[carafelix]

The conflicts in the commands file is over jsdoc :sleepy: :disappointed: :stuck_out_tongue_closed_eyes:

Changes from last time:

• narrow at runtime if ctx.from.id (IETF) first portion is ISO-639 compatible
• narrow all appearances of language_codes from string to LanguageCodes type
• DRY toElementals
• squashed some minor commits

Major changes:

• narrow getNearestCommands results into the user locale, fallbacks to all register localizations when the user lang is not known, fallbacks to default if its known but no register localization exist for that lang. Includes ignoreLocalization opt-out flag
• can look for commands in multiple command instances, returns the most similar across all
• added the prefix into return value of getNearestCommand to support commands with custom prefixes at recommendation time

NOTE: Resolving conflicts will block rebasing into next

Once you've resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch.

An option would be to merge next into this branch, and rebase-merge directly into to main.

[roziscoding]

I rebased this on next locally. That's why the force-push :)