Fixing various typos in readme files #2208

Co-authored-by: Konstantin Volkov <k.volkov@flipperdevices.com>

.github/ISSUE_TEMPLATE/03_feature_request.yml

@@ -14,7 +14,7 @@ body:
     description: |
       Please describe your feature request in as many details as possible.
         - Describe what it should do.
-        - Note whetever it is to extend existing functionality or introduce new functionality.
+        - Note whether it is to extend existing functionality or introduce new functionality.
   validations:
     required: true
 - type: textarea

CODING_STYLE.md

@@ -3,15 +3,15 @@
 Nice to see you reading this document, we really appreciate it.
 
 As all documents of this kind it's unable to cover everything.
-But it will cover general rules that we enforcing on PR review.
+But it will cover general rules that we are enforcing on PR review.
 
-Also we already have automatic rules checking and formatting,
-but it got it's limitations and this guide is still mandatory.
+Also, we already have automatic rules checking and formatting,
+but it got its limitations and this guide is still mandatory.
 
-Some part of this project do have it's own naming and coding guides.
+Some part of this project do have its own naming and coding guides.
 For example: assets. Take a look into `ReadMe.md` in assets folder for more details.
 
-Also 3rd party libraries are none of our concern.
+Also, 3rd party libraries are none of our concern.
 
 And yes, this set is not final and we are open to discussion.
 If you want to add/remove/change something here please feel free to open new ticket.
@@ -30,7 +30,7 @@ Our guide is inspired by, but not claiming to be compatible with:
 
 Code we write is intended to be public.
 Avoid one-liners from hell and keep code complexity under control.
-Try to make code self explanatory and add comments if needed.
+Try to make code self-explanatory and add comments if needed.
 Leave references to standards that you are implementing.
 Use project wiki to document new/reverse engineered standards.
 
@@ -89,7 +89,7 @@ Enforced by linter.
 Suffixes:
 
 - `alloc` - allocate and init instance. C style constructor. Returns pointer to instance.
-- `free` - deinit and release instance. C style destructor. Takes pointer to instance.
+- `free` - de-init and release instance. C style destructor. Takes pointer to instance.
 
 # C++ coding style
 

CONTRIBUTING.md

@@ -23,8 +23,8 @@ Before writing code and creating PR make sure that it aligns with our mission an
 - PR that contains code intended to commit crimes is not going to be accepted.
 - Your PR must comply with our [Coding Style](CODING_STYLE.md)
 - Your PR must contain code compatible with project [LICENSE](LICENSE).
-- PR will only be merged if it pass CI/CD.
-- PR will only be merged if it pass review by code owner.
+- PR will only be merged if it passes CI/CD.
+- PR will only be merged if it passes review by code owner.
 
 Feel free to ask questions in issues if you're not sure.
 
@@ -59,7 +59,7 @@ Commit the changes once you are happy with them. Make sure that code compilation
 ### Pull Request
 
 When you're done making the changes, open a pull request, often referred to as a PR. 
-- Fill out the "Ready for review" template so we can review your PR. This template helps reviewers understand your changes and the purpose of your pull request. 
+- Fill out the "Ready for review" template, so we can review your PR. This template helps reviewers understand your changes and the purpose of your pull request. 
 - Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one.
 - Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) so the branch can be updated for a merge.
 Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request for additional information.

assets/dolphin/ReadMe.md

@@ -26,7 +26,7 @@ Version: 1
 - `Name` - name of animation. Must be exact animation directory name.
 - `Min butthurt`, `Max butthurt` - range of dolphin's butthurt for this animation.
 - `Min level`, `Max level` - range of dolphin's level for this animation. If 0, this animation doesn't participate in random idle animation selection and can only be selected by exact name.
-- `Weight` - chance of this animation to be choosen at random animation selection.
+- `Weight` - chance of this animation to be chosen at random animation selection.
 
 Some animations can be excluded from participation in random animation selection, such as `L1_NoSd_128x49`.
 

documentation/AppManifests.md

@@ -57,8 +57,10 @@ The following parameters are used only for [FAPs](./AppsOnSDCard.md):
 * **fap_weburl**: string, may be empty. Application's homepage.
 * **fap_icon_assets**: string. If present defines a folder name to be used for gathering image assets for this application. These images will be preprocessed and built alongside the application. See [FAP assets](./AppsOnSDCard.md#fap-assets) for details.
 * **fap_extbuild**: provides support for parts of application sources to be built by external tools. Contains a list of `ExtFile(path="file name", command="shell command")` definitions. **`fbt`** will run the specified command for each file in the list.
+
 Note that commands are executed at the firmware root folder's root, and all intermediate files must be placed in an application's temporary build folder. For that, you can use pattern expansion by **`fbt`**: `${FAP_WORK_DIR}` will be replaced with the path to the application's temporary build folder, and `${FAP_SRC_DIR}` will be replaced with the path to the application's source folder. You can also use other variables defined internally by **`fbt`**.
 
+
 Example for building an app from Rust sources:
 
 ```python

documentation/AppsOnSDCard.md

@@ -37,7 +37,7 @@ With it, you can debug FAPs as if they were a part of main firmware — inspect
 
 ### Setting up debugging environment
 
-Debugging support script looks up debugging information in latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
+Debugging support script looks up debugging information in the latest firmware build dir (`build/latest`). That directory is symlinked by fbt to the latest firmware configuration (Debug or Release) build dir, when you run `./fbt` for chosen configuration. See [fbt docs](./fbt.md#nb) for details.
 
 So, to debug FAPs, do the following:
 1. Build firmware with `./fbt`

documentation/file_formats/BadUsbScriptFormat.md

@@ -1,5 +1,5 @@
 # Command syntax
-BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more fuctional keys.
+BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts, but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command and more functional keys.
 # Script file format
 BadUsb app can execute only text scrips from .txt files, no compilation is required. Both `\n` and `\r\n` line endings are supported. Empty lines are allowed. You can use spaces ore tabs for line indentation.
 # Command set

documentation/file_formats/InfraredFileFormats.md

@@ -95,17 +95,17 @@ Note: a single parsed signal must be represented as an array of size 1.
 | data       | raw          | uint32 | Ditto. |
 
 #### Signal names
-The signal names in an `.irtest` file folow a convention `<name><test_number>`, where the name is one of:
+The signal names in an `.irtest` file follow a convention `<name><test_number>`, where the name is one of:
 - decoder_input
 - decoder_expected
 - encoder_decoder_input,
 
 and the number is a sequential integer: 1, 2, 3...etc, which produces names like `decoder_input1`, `encoder_decoder_input3`, and so on.
 
-| Name                  | Type         | Description |
-| --------------------- | ------------ | ----------- |
-| decoder_input         | raw          | A raw signal contaning the decoder input. Is also used as the expected encoder output. |
+| Name                  | Type         | Description                                                                                           |
+| --------------------- | ------------ |-------------------------------------------------------------------------------------------------------|
+| decoder_input         | raw          | A raw signal containing the decoder input. Is also used as the expected encoder output.               |
 | decoder_expected      | parsed_array | An array of parsed signals containing the expected decoder output. Is also used as the encoder input. |
-| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
+| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output.             |
 
 See [Unit Tests](/documentation/UnitTests.md#infrared) for more info.

documentation/file_formats/NfcFileFormats.md

@@ -68,7 +68,7 @@ This file format is used to store the UID, SAK and ATQA of a Mifare Ultralight/N
 
 The "Signature" field contains the reply of the tag to the READ_SIG command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 31)
 
-The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the responce of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
+The "Mifare version" field is not related to the file format version, but to the Mifare Ultralight version. It contains the response of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
 
 Other fields are the direct representation of the card's internal state, more on them can be found in the same datasheet.
 

documentation/file_formats/SubGhzFileFormats.md

@@ -197,7 +197,7 @@ For each key, a name and encryption method must be specified, according to comme
 
 ## SubGhz `setting_user` File
 
-This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is be loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
+This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is being loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
 
 ### File Format
 

firmware/ReadMe.md

@@ -14,7 +14,7 @@ What does it do?
 |-----------|-------------------|-----------------------|-----------------------|
 | f7        | 0x08000000        | L+Back, release both  | L+Back, release Back  |
 
-Also there is a "hardware" ST bootloader combo available even on a bricked or empty device: L+Ok+Back, release Back, Left.
+Also, there is a "hardware" ST bootloader combo available even on a bricked or empty device: L+Ok+Back, release Back, Left.
 Target independent code and headers in `target/include` folders. More details in `documentation/KeyCombo.md`
 
 # Building

lib/ReadMe.md

@@ -11,7 +11,7 @@
 - `infrared`            - Infrared library
 - `libusb_stm32`        - STM32 USB library
 - `littlefs`            - Internal storage file system
-- `micro-ecc`           - Elliptic Curve Crpytography library
+- `micro-ecc`           - Elliptic Curve Crytography library
 - `microtar`            - TAR archive support library
 - `mlib`                - Algorithms and containers
 - `nanopb`              - Nano Protobuf library

scripts/ReadMe.md

@@ -27,14 +27,14 @@ Also display type, region and etc...
 ## Core1 and Core2 firmware flashing
 
 Core2 goes first, then Core1.
-Never flash FUS or you will loose your job, girlfriend and keys in secure enclave.
+Never flash FUS or you will lose your job, girlfriend and keys in secure enclave.
 
 ## Option Bytes
 
 !!! Setting incorrect Option Bytes may brick your MCU !!!
 
 Defaults are mostly OK, but there are couple things that we'd like to tune.
-Also OB may be damaged, so we've made couple scripts to check and set option bytes.
+Also, OB may be damaged, so we've made couple scripts to check and set option bytes.
 
 !!! Setting incorrect Option Bytes may brick your MCU !!!