refactor(commands): add localization to commands

[JPBM135]

My pt-BR when? 🥲

How?

• i18next now supports a new namespace (fancy name for file) called commands.json, which is accessible through the commands: prefix under any valid key.
• The command file uses an object-like structure (see details below).
• All options are mapped by name, with the exception of choices which are mapped by value.
• To take easy on crowding and remove duplicated stuff, the structure contains a commons object for things like hide or duration, the thing is some commands use a slightly different option, e.g: the ban command which has the default days as 0, not consistent with all other properties which have the default to 1. Because of this, the commons have a reasonably specific override property (see below).

This close #1123

JSON strucuture

category -> command.name ⮡ sub_command_group.name -> sub_command?.name -> option?.name -> choices?.value ⮡ sub_command.name -> option?.name -> choices?.value ⮡ option?.name -> choices?.value

Override system

Using the ban command for exemplification:

We have the common option for days:

"days": {
	"name": "days",
	"description": "The amount of days to delete messages for",
	"choices": {
		"0": "0 days",
		"1": "1 day (default)",
		"2": "2 days",
		"3": "3 days",
		"4": "4 days",
		"5": "5 days",
		"6": "6 days",
		"7": "7 days"
	}
},

But the ban command uses 0 as default, we can override only the choices portion of the days commons declaring it on the ban command:

"ban": {
	"name": "ban",
	"description": "Ban a member of(f) this guild",
	"options": {
		"days": {
			"choices": {
				"0": "0 days (default)",
				"1": "1 day",
			}
		}
	}
},

Resulting in:

{
    "name": "days",
    "description": "The amount of days to delete messages for",
    "type": 4,
    "choices": [
        {
            "name": "0 days (default)",
            "value": 0,
            "name_localizations": {
                "en-US": "0 days (default)"
            }
        },
        {
            "name": "1 day",
            "value": 1,
            "name_localizations": {
                "en-US": "1 day"
            }
        },
        {
            "name": "2 days",
            "value": 2,
            "name_localizations": {
                "en-US": "2 days"
            }
        },
        {
            "name": "3 days",
            "value": 3,
            "name_localizations": {
                "en-US": "3 days"
            }
        },
        {
            "name": "4 days",
            "value": 4,
            "name_localizations": {
                "en-US": "4 days"
            }
        },
        {
            "name": "5 days",
            "value": 5,
            "name_localizations": {
                "en-US": "5 days"
            }
        },
        {
            "name": "6 days",
            "value": 6,
            "name_localizations": {
                "en-US": "6 days"
            }
        },
        {
            "name": "7 days",
            "value": 7,
            "name_localizations": {
                "en-US": "7 days"
            }
        }
    ]
}

The system will get the name and description properties from the commons but will use the overriding choices from the ban command

[vercel[bot]]

@JPBM135 is attempting to deploy a commit to the discordjs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated
yuudachi-report	⬜️ Ignored (Inspect)		Nov 29, 2022 at 2:30AM (UTC)

[iCrawl]

One thing I can spot right now is:

• Move the types.ts file for localizations to @yuudachi/framework maybe? Seems pretty generic to me and useful for everyone that uses the framework
• Move the formatting functions maybe to @yuudachi/framework too?

This way things are nicely separated between "this is part of the framework" and "this is part of yuudachi specific code"

[JPBM135]

One thing I can spot right now is:

• Move the types.ts file for localizations to @yuudachi/framework maybe? Seems pretty generic to me and useful for everyone that uses the framework
• Move the formatting functions maybe to @yuudachi/framework too?

This way things are nicely separated between "this is part of the framework" and "this is part of yuudachi specific code"

I agree with this, makes total sense to move the generic stuff to the framework

[JPBM135]

I should probably add some comments for things like fallbackLng: 'dev'

[JPBM135]

• [ ] Add comments to sketchy stuff
• [ ] Move types to the framework
• [ ] Move common functions to the framework