[Docs] Minor typofixes/addendums to .md files (#6817)

* [Docs] Minor typofixes to `.md` files

* Fixed footnotes

* Update linting.md to remove comment

* Added footnote for validation workflow

CONTRIBUTING.md

@@ -26,9 +26,9 @@ If you use any external code, please make sure to follow its licensing informati
 
 ## 🛠️ Development Basics
 
-PokéRogue is built with [Typescript](https://www.typescriptlang.org/docs/handbook/intro.html), using the [Phaser](https://github.com/phaserjs/phaser) game framework.
+PokéRogue is built with [TypeScript](https://www.typescriptlang.org/docs/handbook/intro.html), using the [Phaser](https://github.com/phaserjs/phaser) game framework.
 
-If you have the motivation and experience with Typescript/Javascript (or are willing to learn), you can contribute by forking the repository and making pull requests with contributions.
+If you have the motivation and experience with TypeScript/JavaScript (or are willing to learn), you can contribute by forking the repository and making pull requests with contributions.
 
 ## 💻 Environment Setup
 
@@ -97,7 +97,8 @@ Notable topics include:
 - [Commenting your code](./docs/comments.md)
 - [Linting & Formatting](./docs/linting.md)
 - [Localization](./docs/localization.md)
-- [Enemy AI move selection](./docs/enemy-ai.md) 
+- [Enemy AI move selection](./docs/enemy-ai.md)
+- [Running with Podman](./docs/podman.md)
 
 Again, if you have unanswered questions please feel free to ask!
 

docs/linting.md

@@ -18,7 +18,7 @@ For the most part, Biome attempts to stay "out of your hair", letting you write
 On the other hand, if Biome complains about a piece of code, **there's probably a good reason why**. Disable comments should be used sparingly or when readabilty demands it - your first instinct should be to fix the code in question, not disable the rule.
 
 ## Editor Integration
-Biome has integration with many popular code editors. See [these](https://biomejs.dev/guides/editors/first-party-extensions/) [pages](https://biomejs.dev/guides/editors/third-party-extensions/) for information about enabling Biome in your editor of choice.
+Biome has integrations with many popular code editors. See [these](https://biomejs.dev/guides/editors/first-party-extensions/) [pages](https://biomejs.dev/guides/editors/third-party-extensions/) for information about enabling Biome in your editor of choice.
 
 ## Automated Runs
 Generally speaking, most users shouldn't need to run Biome directly; in addition to editor integration, a [pre-commit hook](../lefthook.yml) will automatically format and lint all staged files before each commit.
@@ -32,7 +32,7 @@ We also have a [Github Action](../.github/workflows/linting.yml) to verify code
 These are effectively the same commands as run by Lefthook, merely on a project-wide scale.
 
 ## Running Biome via CLI
-To run you Biome on your files manually, you have 2 main options:
+To run Biome on your files manually, you have 2 main options:
 1. Run the scripts included in `package.json` (`pnpm biome` and `pnpm biome:all`). \
     These have sensible defaults for command-line options, but do not allow altering certain flags (as some cannot be specified twice in the same command)
 
@@ -50,14 +50,11 @@ A full list of flags and options can be found on [their website](https://biomejs
 
 ## Linting Rules
 
-We primarily use Biome's [recommended ruleset](https://biomejs.dev/linter/rules/) for linting JS/TS files, with some customizations to better suit our project's needs[^1].
+We primarily use Biome's [recommended ruleset](https://biomejs.dev/linter/rules/) for linting JS/TS files, with some customizations to better suit our project's needs. \
+A complete list of rules can be found in the [`biome.jsonc`](../biome.jsonc) file in the project root. Most rules are accompanied by comments explaining the reasons for their inclusion/exclusion.
 
-Some things to consider:
+> [!IMPORTANT]
-
+> Certain lint rules may be marked as `info` or `warn` to allow for gradual refactoring without blocking development.
-- We have disabled rules that prioritize style over performance, such as `useTemplate`.
+> **Do not write new code that triggers these rules!**
-- Some rules are currently marked as warnings (`warn`) to allow for gradual refactoring without blocking development. **Do not write new code that triggers these rules!**
-- The linter is configured to ignore specific files and folders (such as excessively large files or ones in need of refactoring) to improve performance and focus on actionable areas.
 
 Any questions about linting rules can be brought up in the `#dev-corner` channel in the community Discord.
-
-[^1]: A complete list of rules can be found in the [`biome.jsonc`](../biome.jsonc) file in the project root. Many rules are accompanied by comments explaining the reasons for their inclusion (or lack thereof).

docs/localization.md

@@ -28,7 +28,7 @@ This repository is integrated into the main one as a [git submodule](https://git
 In essence, a submodule is a way for one repository (i.e. `pokerogue`) to use another repository (i.e. `pokerogue-locales`) internally.
 The parent repo (the "superproject") houses a cloned version of the 2nd repository (the "submodule") inside it, making locales effectively a "repository within a repository", so to speak.
 
->[!TIP]
+> [!TIP]
 > Many popular IDEs have integrated `git` support with special handling around submodules:
 >
 > ![Image showing Visual Studio Code's `git` integration in the File Explorer. A blue "S" in the top right hand corner indicates the `locales` folder is a submodule.](https://github.com/user-attachments/assets/00674c3f-72ee-42f7-8b09-4008d466b263 "What the `locales` submodule looks like in VS Code's File Explorer")
@@ -97,17 +97,23 @@ If this feature requires new text, the text should be integrated into the code w
     - For any feature pulled from the mainline Pokémon games (e.g. a Move or Ability implementation), it's best practice to include a source link for any added text. \
     [Poké Corpus](https://abcboy101.github.io/poke-corpus/) is a great resource for finding text from the mainline games; otherwise, a video/picture showing the text being displayed should suffice.
     - You should also [notify the current Head of Translation](#notifying-translation) to ensure a fast response.
-3. Your locales should use the following format:
+3. At this point, you may begin [testing locales integration in your main PR](#documenting-locales-changes).
-  - File names should be in `kebab-case`. Example: `trainer-names.json`
+4. The Translation Team will approve the locales PR (after corrections, if necessary), then merge it into `pokerogue-locales`.
-  - Key names should be in `camelCase`. Example: `aceTrainer`
+5. The Dev Team will approve your main PR for your feature, then merge it into PokéRogue's beta environment.
-    - If you make use of i18next's inbuilt [context support](https://www.i18next.com/translation-function/context), you need to use `snake_case` for the context key. Example: `aceTrainer_male`
-4. At this point, you may begin [testing locales integration in your main PR](#documenting-locales-changes).
-5. The Translation Team will approve the locales PR (after corrections, if necessary), then merge it into `pokerogue-locales`.
-6. The Dev Team will approve your main PR for your feature, then merge it into PokéRogue's beta environment.
 
 [^2]: For those wondering, the reason for choosing English specifically is due to it being the master language set in Pontoon (the program used by the Translation Team to perform locale updates).
 If a key is present in any language _except_ the master language, it won't appear anywhere else in the translation tool, rendering missing English keys quite a hassle.
 
+> [!IMPORTANT]
+> The Dev and Translation teams have strict requirements for ensuring consistency of newly added locales entries.
+> PRs failing these requirements **will not be mergeable into `locales`**!  
+> - File names should be in `kebab-case`. Example: `trainer-names.json`
+> - Key names should be in `camelCase`. Example: `aceTrainer`
+> - Keys making use of i18next's inbuilt [context support](https://www.i18next.com/translation-function/context) must use `snake_case` for the context extension[^3]. Example: `aceTrainer_male`
+
+[^3]: If your PR introduces a new context extension not already used in the codebase, the validation workflow will be unable to detect it and flag it as invalid. \
+To fix this, update the [`i18nextKeyExtensions`](https://github.com/pagefaultgames/pokerogue-locales/blob/main/.github/scripts/locales-format-checker/constants.js#L30) array with the new entries.
+
 ### Requirements for Modifying Translated Text
 
 PRs that modify existing text have different risks with respect to coordination between development and translation, so their requirements are slightly different:
@@ -130,9 +136,9 @@ The basic procedure is roughly as follows:
     ```
 2. Set some of the [in-game overrides](../CONTRIBUTING.md#1---manual-testing) inside `overrides.ts` to values corresponding to the interactions being tested.
 3. Start a local dev server (`pnpm start:dev`) and open localhost in your browser.
-4. Take screenshots or record a video of the locales changes being displayed in-game using the software of your choice[^2].
+4. Take screenshots or record a video of the locales changes being displayed in-game using the software of your choice[^3].
 
-[^2]: For those lacking a screen capture device, [OBS Studio](https://obsproject.com) is a popular open-source option.
+[^3]: For those lacking a screen capture device, [OBS Studio](https://obsproject.com) is a popular open-source option.
 
 > [!NOTE]
 > For those aiming to film their changes, bear in mind that GitHub has a hard **10mB limit** on uploaded media content.