fix(docs): typos (#10143)

docs/Build LogSeq Desktop for windows on Ubuntu.md

@@ -1,7 +1,7 @@
 # Building Logseq Desktop app for Windows on Ubuntu
 ## Intro
 My Logseq dev machine is on Ubuntu 18.x and my production machine is running Windows 10, I needed a way to compile the Logseq desktop APP for Windows.
-I tired & failed to make the "build" run on my windows machine but I did, however, succeed in letting my Ubuntu machine make Windows x64 files
+I tried & failed to make the "build" run on my windows machine but I did, however, succeed in letting my Ubuntu machine make Windows x64 files
 ## Pre-requisites
 These are the steps I took to make it work on my Ubuntu machine, sharing them hoping it helps someone else. I assume you have all the basic pre-requisites for Logseq, if not you can find them at https://github.com/logseq/logseq#1-requirements
 1. clone Logseq repo if you haven't already

docs/accessibility.md

@@ -1,12 +1,12 @@
-- Accessibility is a vague term, which is why it is usually misunderstood. It is not just about people with with specific disabilities. You can read more about [what is accessibility](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility#so_what_is_accessibility) and [diverse abilities and barriers](https://www.w3.org/WAI/people-use-web/abilities-barriers/).
+- Accessibility is a vague term, which is why it is usually misunderstood. It is not just about people with specific disabilities. You can read more about [what is accessibility](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility#so_what_is_accessibility) and [diverse abilities and barriers](https://www.w3.org/WAI/people-use-web/abilities-barriers/).
 - ## Web Content Accessibility Guidelines
 	- [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) (Web Content Accessibility Guidelines) is the international standard for web content accessibility, developed by [W3C](https://www.w3.org/). Logseq is a web application, so conforming with WCAG should be our first priority. In general, there is no simple way to determine if a website is accessible or not, but WCAG can help us make the tool usable by as many people as possible.
 - ## Levels of conformance
 	- There are three levels of conformance defined by WCAG
 		- Level **A** is the minimum level.
 		- Level **AA** includes all Level A and AA requirements.
 		- Level **AAA** includes all Level A, AA, and AAA requirements.
-	- Many organizations strive to meet Level AA. The reason behind this decision, is that in some cases AAA standard is too strict. That does't mean that triple-A issues should be disregarded. On the contrary, all of them should be handled if possible.
+	- Many organizations strive to meet Level AA. The reason behind this decision, is that in some cases AAA standard is too strict. That doesn't mean that triple-A issues should be disregarded. On the contrary, all of them should be handled if possible.
 	- We can also provide alternative options in order to conform with AAA standards. For instance, our default themes can aim for AA, but we can provide a high-contrast theme that aims for AAA. Providing [alternative versions](https://www.w3.org/WAI/GL/2007/05/alternate-versions.html) with different levels of conformance is permitted according to WCAG, if there is an accessible way to reach those alternatives.
 - ## Simple development guidelines
 	- Use semantically correct markup whenever possible. Every time you are about to decide which html tag you are going to use, choose the one that behaves the way you want it. For example, let's say you want to create an element that looks like plain text, but triggers an action on click. Usually, the best approach would be to create a `<button>` and make it look like a `<span>` using css. If you use a `span`, you will also have to override other html attributes like `tabindex` and `role` to make the element behave like a button. This is almost always a bad sign, and should be avoided. If you use the appropriate html element, the browser will be able to properly handle it.
@@ -18,7 +18,7 @@
 	- There is a [huge list of tools](https://www.w3.org/WAI/ER/tools/) that can help us test our application. Most of them use [axe-core](https://github.com/dequelabs/axe-core) internally. There are [browser extensions](https://www.deque.com/axe/browser-extensions/) based on axe, a [VSCode Linter Plugin](https://marketplace.visualstudio.com/items?itemName=deque-systems.vscode-axe-linter) and also [multiple community projects](https://github.com/dequelabs/axe-core/blob/develop/doc/projects.md#community-projects).
 	- Basic accessibility testing could be integrated into our CI, by using the appropriate axe package (e.g. [@axe-core/playwright](https://github.com/dequelabs/axe-core-npm/blob/develop/packages/playwright/README.md))
 - ## Manual testing
-	- In theory, all of the cases described by WCAG should be testable. In practice, there are issues that can't be replicated by code. Also, manual accessibility testing would help us have a better understanding of the difficulties that certain people might encounter. Even if the all the individual cases pass the tests, the overall navigation might be nonsensical.
+	- In theory, all of the cases described by WCAG should be testable. In practice, there are issues that can't be replicated by code. Also, manual accessibility testing would help us have a better understanding of the difficulties that certain people might encounter. Even if all the individual cases pass the tests, the overall navigation might be nonsensical.
 	- ### Manual accessibility testing musts
 		- Keyboard-only navigation
 		- Screen reader testing and compatibility

docs/contributing-to-translations.md

@@ -14,7 +14,7 @@ In order to run the commands in this doc, you will need to install
 ## Where to Contribute
 
 Language translations are under,
-[src/resources/dicts/](https://github.com/logseq/logseq/blob/master/src/resources/dicts/) with each language having it's own file. For example, the es locale is in `es.edn`.
+[src/resources/dicts/](https://github.com/logseq/logseq/blob/master/src/resources/dicts/) with each language having its own file. For example, the es locale is in `es.edn`.
 
 ## Language Overview
 
@@ -83,7 +83,7 @@ Almost all translations are small. The only exceptions to this are the keys `:tu
 ### Editing Tips
 
 * Some translations may include punctuation like `:` or `!`. When translating them, please use the punctuation that makes the most sense for your language as you don't have to follow the English ones.
-* Some translations may include arguments/interpolations e.g. `{1}`. If you see them in a translation, be sure to include them. These arguments are substituted in the string and are usually used something the app needs to calculate e.g. a number. See [these docs](https://github.com/tonsky/tongue#interpolation) for more examples.
+* Some translations may include arguments/interpolations e.g. `{1}`. If you see them in a translation, be sure to include them. These arguments are substituted in the string and are usually used for something the app needs to calculate e.g. a number. See [these docs](https://github.com/tonsky/tongue#interpolation) for more examples.
 * Rarely, a translation may need to translate formatted text by returning [hiccup-style HTML](https://github.com/weavejester/hiccup#syntax). In this case, a Clojure function is the recommended approach. For example, a function translation would look like `(fn [] [:div "FOO"])`. See `:on-boarding/main-title` for an example.
 ## Fix Mistakes
 
@@ -105,4 +105,4 @@ To add a new language:
 * Add an entry to `frontend.dicts/languages`
 * Create a new file under `src/resources/dicts/` and name the file the same as the locale e.g. zz.edn for a hypothetical zz locale.
 * Add an entry in `frontend.dicts/dicts` referencing the file you created.
-* Then start translating for your language and adding entries in your language's EDN file using the `bb lang:missing` workflow.
+* Then start translating for your language and adding entries in your language's EDN file using the `bb lang:missing` workflow.

src/resources/tutorials/tutorial-fr.md

@@ -8,7 +8,7 @@ Appuyez sur `Entrée` pour créer un nouveau bloc.
 Appuyez sur `Maj+Entrée` pour créer une nouvelle ligne.
 Tapez `/` pour afficher toutes les commandes.
 #+END_TIP
-- 1. Créeons une page appelée [[Comment prendre des notes factices ?]]. Vous pouvez cliquer pour aller sur cette page, ou vous pouvez faire `Maj+clic` pour l'ouvrir dans la barre latérale droite. Maintenant, vous devriez voir les _Références liées_  et les _Références non-liées_.
+- 1. Créons une page appelée [[Comment prendre des notes factices ?]]. Vous pouvez cliquer pour aller sur cette page, ou vous pouvez faire `Maj+clic` pour l'ouvrir dans la barre latérale droite. Maintenant, vous devriez voir les _Références liées_  et les _Références non-liées_.
 - 2. Maintenant, référençons quelques blocs sur [[Comment prendre des notes factices ?]], vous pouvez faire `Maj+clic` sur la référence de n'importe quel bloc pour l'ouvrir dans la barre latérale droite. Essayez de faire quelques changements depuis la barre latérale droite, les blocs référencés devraient changer également !
     - ((5f713e91-8a3c-4b04-a33a-c39482428e2d)) : Il s'agit d'une référence de bloc.
     - ((5f713ea8-8cba-403d-ac00-9964b1ec7190)) : Voici une autre référence de bloc.