Typo Fixes (#618)

Author: johnzhou721

content/community/resources/pycon-au-2015-python-on-the-move/contents.lr

@@ -4,7 +4,7 @@ description:
 
 Over the last 5-10 years, the "desktop/server" split that dominated computing in the 80s, 90s and early 2000s has been joined by a third player - mobile devices such as phones and tablets.
 
-So, what is the story for running Python on these devices? Although there hasn't been much to say in the past, the good news is that over the last year, there's been some signficant changes in the landscape, and Python on Mobile is now teetering on the brink of being a genuine reality.
+So, what is the story for running Python on these devices? Although there hasn't been much to say in the past, the good news is that over the last year, there's been some significant changes in the landscape, and Python on Mobile is now teetering on the brink of being a genuine reality.
 
 In this talk, Dr Russell Keith-Magee will survey the current state of using Python on mobile devices, the work that is currently being done, areas where more work is required, and the prospects for the future.
 ---

content/contributing/first-time/what/contents.lr

@@ -86,7 +86,7 @@ implement that widget for your platform of choice!
 Even if you *don't* know a native widget library, you may still be able to help
 with Toga. Writing new widgets is a lot less complicated than it may seem.
 Every platform has documentation for how to use their native APIs, and the
-process of translating that platform documentation from another langauge (e.g.,
+process of translating that platform documentation from another language (e.g.,
 Objective C or C#) is a relatively straightforward process. The existing code
 should give you some pointers of how this can be done, and the BeeWare team is
 happy to help if you need it. Jump on the `BeeWare Discord

content/contributing/translations/contents.lr

@@ -14,7 +14,7 @@ Want to help translate or update the content of this website?
 The contents of these pages are mostly written in `Lektor (.lr) files
 <https://www.getlektor.com/docs/content/>`__ and `.ini databags
 <https://www.getlektor.com/docs/content/databags/>`__. To translate a page,
-choose the desired langauge using the globe in the top right and then click
+choose the desired language using the globe in the top right and then click
 "Edit on GitHub". To translate the databags, `open a .ini file
 <https://github.com/beeware/beeware.github.io/tree/lektor/databags>`__ and
 create or edit the section for the specified language (e.g., ``[pt]`` for

content/news/buzz/2017-google-summer-of-code-final-report-dayanne-fernandes/contents.lr

@@ -16,7 +16,7 @@ After almost 4 months of work on `Google Summer of Code`_ 2017, finally I'm comp
 
 The best way to show that a product is reliable to the customers is use it. So, the way to show that `Toga`_ is an effective tool to build a GUI is to build a complete application using it.
 
-`Cricket`_ is a graphical tool that helps you run your test suites. Its current version is implemented using `Tkinter`_ as the main GUI framework. So, why not test `Toga`_ inside of another product from `BeeWare`_? That's what I have acomplished during my GSoC work.
+`Cricket`_ is a graphical tool that helps you run your test suites. Its current version is implemented using `Tkinter`_ as the main GUI framework. So, why not test `Toga`_ inside of another product from `BeeWare`_? That's what I have accomplished during my GSoC work.
 
 Results
 --------
@@ -27,7 +27,7 @@ The proposal focus not only on the port of `Tkinter`_ to `Toga`_, but on mapping
 .. _Cocoa: http://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/Cocoa.html
 .. _CSS: https://www.w3.org/Style/CSS/
 
-The work I did during GSoC were sent throught the `PR 65`_, reported on the `Issue 58`_ and the final demonstration of the work can be seen in this `link`_. There were widgets used on `Cricket`_ that weren't ready yet on `Toga`_, so some improvements were necessary on `Toga`_ so that I could use them on `Cricket`_. In summary here are some PRs and issues that I contributed to get my work done in `Cricket`_:
+The work I did during GSoC were sent through the `PR 65`_, reported on the `Issue 58`_ and the final demonstration of the work can be seen in this `link`_. There were widgets used on `Cricket`_ that weren't ready yet on `Toga`_, so some improvements were necessary on `Toga`_ so that I could use them on `Cricket`_. In summary here are some PRs and issues that I contributed to get my work done in `Cricket`_:
 
 Open PR that I sent to `Toga`_:
 
@@ -154,7 +154,7 @@ Also, there are some issues remained after this migration to `Toga`_. These issu
 * A gap between the output and error boxes when there is no output message
 * Run a test if the user click on it
 
-I truly believe that `Toga`_ will be the oficial framework on Python to build GUI for multiplatforms applications, so I'll continue to contribute to this project because I want to use in every application that I would need a GUI.
+I truly believe that `Toga`_ will be the official framework on Python to build GUI for multiplatforms applications, so I'll continue to contribute to this project because I want to use in every application that I would need a GUI.
 
 Final Considerations
 ---------------------

content/news/buzz/2018-google-summer-of-code-final-report-patience-shyu/contents.lr

@@ -102,7 +102,7 @@ the motivation for the `nested loops optimization`_.
 If I may be a bit more reflective here, one of the a-ha! moments I had this summer was realizing that to really
 optimize something, you have to understand where its biggest problems are first. I remember pitching to Russ at
 the start of the summer things like loop unrolling, constant folding, even converting to SSA-form (you know, stuff I
-heard about optimzation in my compilers class) and he was saying to me, think simpler. While working on my project,
+heard about optimization in my compilers class) and he was saying to me, think simpler. While working on my project,
 I used a `profiler`_ to understand exactly which parts of VOC were slow, and that information drove the changes we
 implemented. I think it worked out pretty well!
 

content/news/buzz/2022q3-roadmap/contents.lr

@@ -44,7 +44,7 @@ The biggest caveat on BeeWare's mobile app story has always been that we don't p
 
 There are already tools like `crossenv <https://github.com/benfogle/crossenv>`__ that can simplify this process, and we've got `a PR in our review queue <https://github.com/beeware/briefcase/pull/647>`__ that provides a proof-of-concept implementation of Android binary packaging. We need to take these tools, plus other tools in the Python ecosystem, and extend Briefcase so that we can present a clear development story for mobile developers that want to use modules with binary components.
 
-On iOS, there is an additional complication - we need to resolve how to manage dynamic loading of modules. BeeWare's iOS support currently relies on static compilation of all binary modules. This was originally done because prior to iOS8, dynamic linking was prohibited on iOS. The days of iOS8 are now long behind us; but the Apple support package has retained this old approach, mostly because it wasn't clear what approach Apple would allow through the App Store review process. We will be making changes to Briefcase's iOS support to accomodate dynamic module loading, and then extending that support to include user-provided binary modules.
+On iOS, there is an additional complication - we need to resolve how to manage dynamic loading of modules. BeeWare's iOS support currently relies on static compilation of all binary modules. This was originally done because prior to iOS8, dynamic linking was prohibited on iOS. The days of iOS8 are now long behind us; but the Apple support package has retained this old approach, mostly because it wasn't clear what approach Apple would allow through the App Store review process. We will be making changes to Briefcase's iOS support to accommodate dynamic module loading, and then extending that support to include user-provided binary modules.
 
 Testing (especially GUI testing)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

content/news/buzz/a-request-for-your-help/contents.lr

@@ -12,11 +12,11 @@ For most of this time, BeeWare has been a volunteer effort. Initially, it was a
 
 .. _Challenge Coins: /contributing/challenge-coins/
 
-Of particular note is the `team of 7 people`_ who have joined the project as apiarists, helping share the load of project maintainence. I can't thank these people enough - without their assistance, I wouldn't have made anywhere near as much progress over the last year.
+Of particular note is the `team of 7 people`_ who have joined the project as apiarists, helping share the load of project maintenance. I can't thank these people enough - without their assistance, I wouldn't have made anywhere near as much progress over the last year.
 
 .. _team of 7 people: /about/team/
 
-You may have noticed that over the last few months, progress has been especially rapid. This is because, for the last six months, BeeWare development has been partially funded by very accomodating employers at `Jambon Software`_. My contract with Jambon allowed me to spend significant periods of time being paid to work on BeeWare - and, not surprisingly, it was possible to make enormous progress as a result. The last 6 months has seen:
+You may have noticed that over the last few months, progress has been especially rapid. This is because, for the last six months, BeeWare development has been partially funded by very accommodating employers at `Jambon Software`_. My contract with Jambon allowed me to spend significant periods of time being paid to work on BeeWare - and, not surprisingly, it was possible to make enormous progress as a result. The last 6 months has seen:
 
 * Extensive improvements to Batavia and VOC;
 * An Android backend for Toga;

content/news/buzz/april-2025-status-update/contents.lr

@@ -11,7 +11,7 @@ What we've done
 
 * We contributed changes to `the Meson buildsystem <https://github.com/numpy/meson/pull/19>`__ that support building on iOS; we have a `second set of changes <https://github.com/mesonbuild/meson/pull/14541>`__ in review. We also have an `iOS support PR for Meson-python <https://github.com/mesonbuild/meson-python/pull/731>`__, the library that provides the PEP 517 build interface for Meson-based Python projects. Work on the `patch for NumPy to support iOS builds <https://github.com/numpy/numpy/pull/28759>`__ also continued.
 
-* We landed some changes to CPython's iOS testbed to `accomodate changes introduced in Xcode 16.3  <https://github.com/python/cpython/pull/133132>`__.
+* We landed some changes to CPython's iOS testbed to `accommodate changes introduced in Xcode 16.3  <https://github.com/python/cpython/pull/133132>`__.
 
 * We modified CPython's iOS compiler shims to ensure `better support for enforcing minimum iOS version levels <https://github.com/python/cpython/pull/133184>`__.
 

content/news/buzz/august-2023-status-update/contents.lr

@@ -13,7 +13,7 @@ What we've done
 
 * The Toga Audit is complete on macOS, iOS and GTK! The last pieces were the audit of `Window <https://github.com/beeware/toga/pull/2058>`__ and `App <https://github.com/beeware/toga/pull/2075>`__; with those PRs (and some others that are outstanding), we have 100% code coverage for Toga's codebase. Windows and Android are catching up rapidly - we've completed the audit of `OptionContainer <https://github.com/beeware/toga/pull/1996>`__, `Table <https://github.com/beeware/toga/pull/2011>`__, and `Tree <https://github.com/beeware/toga/pull/2017>`__, as well as a major revamp of `how layouts are calculated <https://github.com/beeware/toga/pull/2020>`__, which ensures that minimum window sizes are enforced, and layouts on High DPI displays are correct.
 
-* We added a `Texual backend for Toga <https://github.com/beeware/toga/pull/2065>`__. This means the same Toga application will now run on 3 desktop platforms, 2 mobile platforms, as a single page web app, and in a terminal window. As with the web backend, there's still a lot of work to fill out all the widgets, but we've got enough in place to run the BeeWare tutorial app and the first 2 Toga tutorial steps.
+* We added a `Textual backend for Toga <https://github.com/beeware/toga/pull/2065>`__. This means the same Toga application will now run on 3 desktop platforms, 2 mobile platforms, as a single page web app, and in a terminal window. As with the web backend, there's still a lot of work to fill out all the widgets, but we've got enough in place to run the BeeWare tutorial app and the first 2 Toga tutorial steps.
 
 * We `improved the architecture and word size checks that Briefcase performs when building apps <https://github.com/beeware/briefcase/pull/1360>`__. This effectively adds support for 32-bit x86 and ARM platforms; we're limited in our ability to perform automatic tests to verify these platforms work as advertised, and upstream tooling isn't always up to the task (for example, Linuxdeploy doesn't support ARM at any word size) - but Briefcase now performs much more robust checks, and will make a best effort when support *should* exist.
 

content/news/buzz/february-2025-status-update/contents.lr

@@ -17,7 +17,7 @@ What we've done
 
 * We `released Briefcase 0.3.22 <https://pypi.org/project/briefcase/0.3.22/>`__. This is a bug fix release to silence a warning raised during builds caused by the release of pip 25.0. This warning had the potential to become an error at an unknown point in the future, so we decided to push out a low-feature release to avoid that possibility.
 
-* We `released Toga 0.4.9 <https://pypi.org/project/toga/0.4.9/>`__. This release contains only 1 change over the 0.4.8 release - it imposes an upper bound on the version of Travertino that it specifies as a requirement. This ensures that when we release the next version of Travertino, we don't need to accomodate compatibility with Toga 0.4 APIs.
+* We `released Toga 0.4.9 <https://pypi.org/project/toga/0.4.9/>`__. This release contains only 1 change over the 0.4.8 release - it imposes an upper bound on the version of Travertino that it specifies as a requirement. This ensures that when we release the next version of Travertino, we don't need to accommodate compatibility with Toga 0.4 APIs.
 
 * We added `initial support for GTK4 to Toga <https://github.com/beeware/toga/pull/3087>`__. This is only the very initial phases of GTK4 support - most widgets aren't currently supported - but the basic infrastructure that allows a GTK4 app to start *at all* now exists. We now need to go through the process of porting every GTK widget for GTK4 compatibility. Thanks to the work we did on the Toga 0.4 widget audit, we have a comprehensive test suite that we can use to evaluate progress on this task.