[fix]: fix spellings (#2035)

docs/_data/2018.portland.speakers.yaml

@@ -380,7 +380,7 @@
     so that they feel more in control of the technologies they use. My hope is that
     in sharing my experiences, I can engage in a deeper dialogue with the technical
     documentation community about how we can make technical documentation more accessible,
-    easier to re-use, and empowering.</p>'
+    easier to reuse, and empowering.</p>'
   event: Write the Docs PORTLAND 2018
   path: conf/portland/2018/videos/rewrite-the-docs-field-notes-from-the-radical-it-department-camille-acey
   series: Write the Docs PORTLAND

docs/_data/australia-2022-sessions.yaml

@@ -20,7 +20,7 @@
     English content. This is because when sentences are simpler and less ambiguous,
     they become easier and less expensive to translate. </p><p>What qualifies as sustainable
     content and how does STE drive this change towards efficient content management,
-    re-use, and ultimately self-driven workflow processes? </p><p>With over 15 years
+    reuse, and ultimately self-driven workflow processes? </p><p>With over 15 years
     of experience working with software documentation writers who wish to become proficient
     in the STE language standard, we find that many readers and users of their existing
     documentation get confused at times when information is not being conveyed in
@@ -29,7 +29,7 @@
     are used for standardising the English language of your technical content. Thanks
     to this standardisation, a number of benefits towards sustainability can be achieved:</p><ol><li>A
     robust industry-specific terminology</li><li>Leaner translation memories to facilitate
-    re-use</li><li>Technical accuracy.</li></ol>
+    reuse</li><li>Technical accuracy.</li></ol>
 - title: Let's bring science into technical writing
   slug: let-s-bring-science-into-technical-writing-lana
   series: Write the Docs Australia

docs/_data/portland-2020-sessions.yaml

@@ -545,7 +545,7 @@
     national laboratories and universities, we have developed an approach that embraces
     the idea of “document driven development”, by making all our documentation runnable
     within our continuous integration test suite. Most notably, for our tutorials
-    and examples, we re-use a set of Jupyter Notebooks in three ways: as the base
+    and examples, we reuse a set of Jupyter Notebooks in three ways: as the base
     for “live” tutorials and demos, as static documentation disseminated on web pages
     (and other generated forms), and as integration tests that we run in our continuous
     integration system.  While the idea of runnable examples is not new, their full

docs/blog/newsletter-december-2018.rst

@@ -27,7 +27,7 @@ Understanding what users need is at the heart of good technical writing. A recen
 
 * Ask your colleagues: product managers, support/success teams, developers...
 
-  Product mangers often have wide knowledge about user needs. Support can tell you about big and small customer pain points. Developers - particularly experienced ones - can give you insight into use cases, and the needs their code seeks to address.
+  Product managers often have wide knowledge about user needs. Support can tell you about big and small customer pain points. Developers - particularly experienced ones - can give you insight into use cases, and the needs their code seeks to address.
 * Also try reviewing support tickets, for a detailed view on how users really work with the product.
 * Take a look at customer requests, and analyse them carefully. You want to distinguish between what customers ask for, and what they actually need.
 

docs/blog/newsletter-june-2019.rst

@@ -96,7 +96,7 @@ The toolchains also generally differ. Typically, DITA uses a closed content mana
 
 DITA also emphasizes certain features, like content reuse, that don't come out of the box with most docs-as-code tools. However, you can often add those features in - Tom Johnson's `blog series comparing DITA and Jekyll <https://idratherbewriting.com/2015/03/23/new-series-jekyll-versus-dita/>`__ discusses this. He warns that with lots of customisations, you risk locking yourself into a particular toolchain - but others pointed out that it's never "easy" to change docs systems anyway.
 
-Some people pointed out the ideological differences. A lot of the point of DITA is the structure, allowing sophisticated content re-use. Docs-as-code/markdown/SSGs don’t come with the same feature set because they sometimes no have structure at all, even to the point of being anti-structure.
+Some people pointed out the ideological differences. A lot of the point of DITA is the structure, allowing sophisticated content reuse. Docs-as-code/markdown/SSGs don’t come with the same feature set because they sometimes no have structure at all, even to the point of being anti-structure.
 
 So while you can potentially unite the two, it's worth remembering that the philosophies underlying docs-as-code and DITA are quite different.
 

docs/blog/newsletter-october-2019.rst

@@ -65,7 +65,7 @@ A couple of contributors suggested that WTD start its own mentoring program, whi
 Deciding on a new tool...
 -------------------------
 
-If you're struggling with the limitations of your docs tools, how do you decide what system to migrate to? In a recent coversation about trying to replace an old CMS, documentarians on Slack compared MadCap Flare, Paligo, static site generators and Adobe Suite, among others.
+If you're struggling with the limitations of your docs tools, how do you decide what system to migrate to? In a recent conversation about trying to replace an old CMS, documentarians on Slack compared MadCap Flare, Paligo, static site generators and Adobe Suite, among others.
 
 There was some consensus around establishing your specific business requirements before selecting a tool. What outputs do you need to publish? How much do you need to reuse content? Does OS compatibility matter? How long will migration take? The requirements matter because no single tool is right for all situations. If you understand your needs well, it'll really help - you might even realise that you don't need to switch.
 

docs/conf/australia/2023/health.rst

@@ -57,5 +57,5 @@ According to the `current public health guidelines issued by the Victorian Gover
 Thanks
 ------
 
-This COVID policy is largely based on the policy from PyCascades and PyCon US - thank you to the Python Software Foundation for allowing us to modify & re-use your content. 
+This COVID policy is largely based on the policy from PyCascades and PyCon US - thank you to the Python Software Foundation for allowing us to modify & reuse your content. 
 

docs/conf/portland/2023/health.rst

@@ -88,5 +88,5 @@ Changes to this policy will only add requirements, and will not remove requireme
 Thanks
 ------
 
-This COVID policy is largely based on the policy from PyCascades and PyCon US - thank you to the Python Software Foundation for allowing us to modify & re-use your content. 
+This COVID policy is largely based on the policy from PyCascades and PyCon US - thank you to the Python Software Foundation for allowing us to modify & reuse your content.