Closed carafelix closed 4 months ago
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
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? 😅
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, getNearestCommand
calls 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
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
The conflicts in the commands
file is over jsdoc :sleepy: :disappointed: :stuck_out_tongue_closed_eyes:
Changes from last time:
ctx.from.id
(IETF) first portion is ISO-639 compatibleMajor changes:
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 flaggetNearestCommand
to support commands with custom prefixes at recommendation timeNOTE: 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.
I rebased this on next
locally. That's why the force-push :)
Pending:
ctx.from.language_code
(IETF > iso-639), would benefit from https://github.com/grammyjs/types/pull/45/