Merge branch 'cwoolley-gitlab-master-patch-61988' into 'master'

Fix doc wording for GLFM specification dev guide

See merge request gitlab-org/gitlab!85326

doc/development/gitlab_flavored_markdown/specification_guide/index.md

@@ -238,7 +238,7 @@ by a [canonicalization](#canonicalization-of-html) process.
 
 #### Canonicalization of HTML
 
-Neither the backed (Ruby) nor the frontend (JavaScript) rendered can directly render canonical HTML.
+Neither the backend (Ruby) nor the frontend (JavaScript) rendered can directly render canonical HTML.
 Nor should they be able to, because:
 
 - It's not a direct requirement to support any GitLab application feature.
@@ -282,7 +282,7 @@ specification and testing infrastructure:
       which is a [script used to run the Markdown conformance tests](https://github.github.com/gfm/#about-this-document)
       against all examples contained in a `spec.txt`.
 1. The GLFM parsers and HTML renderers for
-   both the static backed (Ruby) and WYSIWYG frontend (JavaScript) implementations
+   both the static backend (Ruby) and WYSIWYG frontend (JavaScript) implementations
    support _consistent_ rendering of all canonical Markdown + HTML examples in the
    GLFM `spec.txt` specification, as verified by `spec_tests.py`.
 
@@ -292,7 +292,7 @@ specification and testing infrastructure:
    to the HTML they render, so therefore their rendered HTML is
    ["canonicalized"](#canonicalization-of-html) to canonical HTML prior running
    the Markdown conformance tests.
-1. For _both_ the static backed (Ruby) and WYSIWYG frontend (JavaScript) implementations,
+1. For _both_ the static backend (Ruby) and WYSIWYG frontend (JavaScript) implementations,
    a set of example snapshots exists in the form of YAML files, which
    correspond to every Markdown example in the GLFM `spec.txt`. These example snapshots
    support the following usages for every GLFM Markdown example:
@@ -570,7 +570,7 @@ The `example_snapshots` directory contains files which are generated by the
 `glfm_specification/input` directory. They are used as fixtures to drive the
 various Markdown snapshot tests.
 
-After the entire GLFM implementation is complete for both backed (Ruby) and
+After the entire GLFM implementation is complete for both backend (Ruby) and
 frontend (JavaScript), all of these YAML files can be automatically generated.
 However, while the implementations are still in progress, the `skip_update_example_snapshots`
 key in `glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml`
@@ -651,7 +651,7 @@ Three types of entries exist, with different HTML for each:
   - For GLFM examples, it is generated/updated from
     `glfm_specification/input/gitlab_flavored_markdown/glfm_canonical_examples.txt`.
 - **Static**
-  - This is the static (backed (Ruby)-generated) HTML for each entry in
+  - This is the static (backend (Ruby)-generated) HTML for each entry in
     `spec/fixtures/glfm/example_snapshots/examples_index.yml`.
   - It is generated/updated from backend [Markdown API](../../../api/markdown.md)
     (or the underlying internal classes) via the `update-example-snapshots.rb` script,