Misc docs cleanup and fixes (#155501)

docs/contributing/Chat.md

@@ -2,7 +2,7 @@
 
 <img src="https://github.com/flutter/flutter/assets/551196/1381071b-e482-4e07-b096-60e9219d3ff7" width=300 align=right alt="">
 
-The Flutter team uses a [Discord server](https://discord.com/channels/608014603317936148). [This is invite link for Flutter's Discord server](https://discord.gg/ht477J5PyH). Please do not share either link directly, instead share links to this page.
+The Flutter team uses a [Discord server](https://discord.com/channels/608014603317936148). [This is the invite link for Flutter's Discord server](https://discord.gg/ht477J5PyH). Please do not share either link directly, instead share links to this page.
 
 The server is open to the public, though some channels are intended only for people who are actively contributing. **See the #welcome channel for instructions on posting to the server (you won't be able to see the channels until you acknowledge the rules there).**
 

docs/contributing/Setting-up-the-Framework-development-environment.md

@@ -1,6 +1,6 @@
-## Preqrequisites
+## Prerequisites
 
- * Linux, Mac OS X, or Windows
+ * Linux, macOS, or Windows
 
  * `git` (used for source version control)
 

docs/contributing/Style-guide-for-Flutter-repo.md

@@ -477,7 +477,7 @@ Unfortunately, the reality is that everyone starts knowing nothing, and we do no
 
 For this reason, avoid using terms without first defining them, unless you are linking to more fundamental documentation that defines that term without reference to the API you are documenting.
 
-For example, a fancy widget in the Material library can refer to the `StatefulWidget` documentation and assume that the reader either knows about the `StatefulWidget` class, or can learn about it by following the link and then later returning to the documentation for the fancy widget. However, the documentation for the `StatefulWidget` class should avoid assuming that the reader knows what a `State` class is, and should avoid defering to it for its definition, because `State` could is likely to defer back to `StatefulWidget` and the reader would be stuck in a loop unable to grasp the basic principles. This is the documentation equivalent of a bootstrapping problem.
+For example, a fancy widget in the Material library can refer to the `StatefulWidget` documentation and assume that the reader either knows about the `StatefulWidget` class, or can learn about it by following the link and then later returning to the documentation for the fancy widget. However, the documentation for the `StatefulWidget` class should avoid assuming that the reader knows what a `State` class is, and should avoid deferring to it for its definition, because `State` could is likely to defer back to `StatefulWidget` and the reader would be stuck in a loop unable to grasp the basic principles. This is the documentation equivalent of a bootstrapping problem.
 
 Another way to express this is that API documentation should follow a similar layering philosophy as code. The goal of documentation is not just to act as a refresher for experts, but to act as a tutorial for new developers.
 
@@ -834,7 +834,7 @@ than "lasagna" code (where each section of the code is cleanly layered and separ
 ### Avoid using `extension`.
 
 Extension methods are confusing to document and discover. To an end developer,
-they appear no different than the built in API of the class, and discovering
+they appear no different than the built-in API of the class, and discovering
 the documentation and implementation of an extension is more challenging than
 for class members.
 
@@ -1169,7 +1169,7 @@ documented top-level library intended to be imported by users.
 
 The definition of "New" changes as code grows and time passes. If the code
 needed a replacement version the odds of needing another replacement in the
-future is higher. Instead find a name that represents the idea being being used
+future is higher. Instead find a name that represents the idea being used
 or replaced.
 
 
@@ -1205,7 +1205,7 @@ Example:
 
 TODOs should include the string TODO in all caps, followed by the GitHub username of
 the person with the best _context_ about the problem referenced by the TODO in
-parenthesis. A TODO is not a commitment that the person referenced will fix the
+parentheses. A TODO is not a commitment that the person referenced will fix the
 problem, it is intended to be the person with enough context to explain the problem.
 Thus, when you create a TODO, it is almost always your username that is given.
 

docs/contributing/issue_hygiene/Making-animated-GIFs-of-Flutter-apps.md

@@ -1,4 +1,4 @@
-Animated GIFs are useful for documentating animations. Here’s how to make them:
+Animated GIFs are useful for documenting animations. Here's how to make them:
 
 ## Capturing video of an Android device
 

docs/contributing/issue_hygiene/Popular-issues.md

@@ -2,7 +2,7 @@ When deciding what to work on, we usually focus on issues that have a lot of thu
 
 Some popular issues are topics on which we cannot find a good way to make progress. Since those issues where we _do_ make progress get closed, the result is that [the list of most-popular issues](https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) is now full of issues where we have conspicuously not made progress!
 
-In the interests of transparency, this wiki page discusses the status of the ten most popular issues. It is only updated occasionally and so may not be entirely up to date; for the most up to date information, please see the latest comments on the relevant issue. (Please avoid asking for an update on issues, otherwise they become full of people asking for updates and nobody can find the actual updates.)
+In the interests of transparency, this wiki page discusses the status of the ten most popular issues. It is only updated occasionally and so may not be entirely up to date; for the most up-to-date information, please see the latest comments on the relevant issue. (Please avoid asking for an update on issues, otherwise they become full of people asking for updates and nobody can find the actual updates.)
 
 _See also: [the list of popular issues including closed issues](https://github.com/flutter/flutter/issues?q=is%3Aissue+sort%3Areactions-%2B1-desc), which shows that popular issues do get closed. 😅_
 

docs/contributing/testing/Flutter-Test-Fonts.md

@@ -18,6 +18,7 @@ Thanks to that, the `FlutterTest` font generally provides more precise and font-
 **Example**
 
 You can expect this test to pass on all platforms (currently with the exception of the web HTML renderer):
+
 ```dart
 final painter = TextPainter(
   text: const TextSpan(
@@ -35,6 +36,7 @@ expect(lineMetrics.descent, 3.5); // 0.25em * 14.0pt
 // 'text' is 4 glyphs. Most glyphs are as wide as they are tall.
 expect(lineMetrics.width, 14.0 * 4);
 ```
+
 While with the `Ahem` font you would get [slightly different metrics on different platforms](https://github.com/flutter/flutter/issues/62819), since they use different font engines to scale the font.
 
 ### Glyphs

docs/contributing/testing/Writing-a-golden-file-test-for-package-flutter.md

@@ -4,7 +4,7 @@ _(This page is referenced by comments in the Flutter codebase.)_
 
 **If you want to learn how to write a golden test for your package, see [the `matchesGoldenFile` API docs](https://api.flutter.dev/flutter/flutter_test/matchesGoldenFile.html).** This wiki page describes the special process specifically for the Flutter team itself.
 
-Golden file tests for `package:flutter` use [Flutter Gold](https://flutter-gold.skia.org/?query=source_type%3Dflutter) for baseline and version management of golden files. This allows for golden file testing on Linux, Windows, MacOS and Web, which accounts for the occasional subtle rendering differences between these platforms.
+Golden file tests for `package:flutter` use [Flutter Gold](https://flutter-gold.skia.org/?query=source_type%3Dflutter) for baseline and version management of golden files. This allows for golden file testing on Linux, Windows, macOS and Web, which accounts for the occasional subtle rendering differences between these platforms.
 
 ## Index
 
@@ -150,9 +150,9 @@ Add an expectation along the following lines:
   );
 ```
 
-The argument to `matchesGoldenFile` is the filename for the screen shot. The part up to the first dot should exactly match the test filename (e.g. if your test is `widgets/foo_bar_test.dart`, use `foo_bar`). The `subtest` part should be unique to this `testWidgets` entry, and the part after that should be unique within the `testWidgets` entry. This allows each file to have multiple `testWidgets` tests each with their own namespace for the images, and then allows for disambiguation within each test in case there are multiple screen shots per test.
+The argument to `matchesGoldenFile` is the filename for the screenshot. The part up to the first dot should exactly match the test filename (e.g. if your test is `widgets/foo_bar_test.dart`, use `foo_bar`). The `subtest` part should be unique to this `testWidgets` entry, and the part after that should be unique within the `testWidgets` entry. This allows each file to have multiple `testWidgets` tests each with their own namespace for the images, and then allows for disambiguation within each test in case there are multiple screenshots per test.
 
-Golden tests may be executed locally on Linux, MacOS, and Windows platforms. All reference images can be found at [Flutter Gold baselines](https://flutter-gold.skia.org/list?fdiffmax=-1&fref=false&frgbamax=255&frgbamin=0&head=true&include=false&limit=50&master=false&match=name&metric=combined&neg=false&new_clstore=true&offset=0&pos=true&query=source_type%3Dflutter&sort=desc&unt=true). Some tests may have multiple golden masters for a given test, to account for rendering differences across platforms. The parameter set for each image is listed in each image digest to differentiate renderings.
+Golden tests may be executed locally on Linux, macOS, and Windows platforms. All reference images can be found at [Flutter Gold baselines](https://flutter-gold.skia.org/list?fdiffmax=-1&fref=false&frgbamax=255&frgbamin=0&head=true&include=false&limit=50&master=false&match=name&metric=combined&neg=false&new_clstore=true&offset=0&pos=true&query=source_type%3Dflutter&sort=desc&unt=true). Some tests may have multiple golden masters for a given test, to account for rendering differences across platforms. The parameter set for each image is listed in each image digest to differentiate renderings.
 
 Once you have written your test, run `flutter test --update-goldens test/foo/bar_test.dart` in the `flutter` package directory (where the filename is the relative path to your new test). This will update the images in `bin/cache/pkg/skia_goldens/packages/flutter/test/`; the directories below that will match the hierarchy of the directories in the `test` directory of the `flutter` package. Verify that the images are what you expect; update your test and repeat this step until you are happy with the image.