[FIX] rdtraining: fix writing errors

closes odoo/documentation#3248

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

content/developer/howtos/rdtraining/E_unittest.rst

@@ -11,9 +11,9 @@ Advanced E: Python Unit Tests
 
 **Reference**:
 `Odoo's Test Framework: Learn Best Practices <https://www.youtube.com/watch?v=JEIscps0OOQ>`__
-(Odoo Experience 2020) on Youtube.
+(Odoo Experience 2020) on YouTube.
 
-Writing tests is a necessity for multiple reasons. Here is a non exhaustive list:
+Writing tests is a necessity for multiple reasons. Here is a non-exhaustive list:
 
 * Ensure it will not be broken in the future
 * Define the scope of your code
@@ -166,8 +166,8 @@ your branch on the target and rerun the tests locally.
 Modules
 =======
 
-Because Odoo is modular, the tests need to be modular also. This means the modules are defined in
-the module that adds the functionality you add; and that tests cannot depend on functionality
+Because Odoo is modular, the tests need to be also modular. This means tests are defined in
+the module that adds the functionality you are adding in, and tests cannot depend on functionality
 coming from modules your module doesn't depend on.
 
 **Reference**: the documentation related to this topic can be found in
@@ -192,21 +192,21 @@ coming from modules your module doesn't depend on.
 
 
 If the behavior you want to test can be changed by the installation of another module, you need to
-ensure that the tag `at_install` is set; otherwise you can use the tag `post_install` to speed up
-the CI, and ensure it is not changed if it shouldn't.
+ensure that the tag `at_install` is set; otherwise, you can use the tag `post_install` to speed up
+the CI and ensure it is not changed if it shouldn't.
 
 Writing a test
 ==============
 
 **Reference**: the documentation related to this topic can be found in
-`Python unittest <https://docs.python.org/3/library/unittest.html>`__.
+`Python unittest <https://docs.python.org/3/library/unittest.html>`__
 and :ref:`Testing Odoo<reference/testing>`.
 
 Here are a few things to take into consideration before writing a test
 
-* The tests should be independent from the data currently in the database (including demo data)
+* The tests should be independent of the data currently in the database (including demo data)
 * Tests should not impact the database by leaving/changing residual data. This is usually done by
-  the test framework by doing a rollback. This is why you must never call ``cr.commit`` in a test
+  the test framework by doing a rollback. Therefore, you must never call ``cr.commit`` in a test
   (nor anywhere else in the business code).
 * For a bug fix, the test should fail before applying the fix and pass after.
 * Don't test something that is already tested elsewhere; you can trust the ORM. Most of the tests
@@ -217,7 +217,7 @@ Here are a few things to take into consideration before writing a test
   in python. This also applies in the tests. If you want to emulate a Form view, you can use
   ``odoo.tests.common.Form``.
 
-The tests should be located in a ``tests`` folder in the root of your module. Each test file name
+The tests should be in a ``tests`` folder at the root of your module. Each test file name
 should start with `test_` and be imported in the ``__init__.py`` of the test folder. You shouldn't
 import the test folder/module in the ``__init__.py`` of the module.
 
@@ -285,9 +285,9 @@ These test classes are built on top of the ``unittest`` python module.
           with self.assertRaises(UserError):
               self.properties.forbidden_action_on_sold_property()
 
-.. note:: For more readability, split your tests into multiple files depending on the scope of the
-  tests. You can also have a Common class that most of the tests should inherit from; that common
-  class can define the whole set up for the module. For instance in
+.. note:: For better readability, split your tests into multiple files depending on the scope of the
+  tests. You can also have a Common class that most of the tests should inherit from; this common
+  class can define the whole setup for the module. For instance, in
   `account <{GITHUB_PATH}/addons/account/tests/common.py>`__.
 
 .. exercise:: Ensure no one can create an offer for a sold Property, and create a test for it.

content/developer/howtos/rdtraining/J_reports.rst

@@ -22,7 +22,7 @@ information in an organized template to support the business in different ways.
 can additionally add our company's header and footer to our reports with minimal extra effort.
 
 The documentation related to this topic can be found in :ref:`reference/qweb`,
-:ref:`reference/reports/report` and the :ref:`reference/actions/report`
+:ref:`reference/reports/report`, and the :ref:`reference/actions/report`
 section of the Actions reference.
 
 File Structure
@@ -31,13 +31,13 @@ File Structure
 The bulk of a PDF report is its QWeb template. It also typically needs a corresponding
 ``ir.actions.report`` to include the report within a module's business logic.
 There is no strict rule for the file names or where they are located, but these two parts are
-typically stored in 2 separate files within a ``report`` folder in the top level of your module's
-directory. If a module has many or multiple long report templates, then they are often organized in
-a logical manner across different files named after the report(s) they contain. All actions
-for the reports are usually stored in the same file ending with ``_report_views.xml`` regardless of the
+typically stored in 2 separate files within a ``report`` folder at the top level of your module's
+directory. If a module has many or multiple long report templates, then they are often organized
+logically across different files named after the report(s) they contain. All actions
+for the reports are usually stored in the same file ending with ``_reports.xml``, regardless of the
 number of reports it contains.
 
-Therefore it is expected that your work tree will look something like:
+Therefore, it is expected that your work tree will look something like this:
 
 .. code-block:: bash
 
@@ -60,8 +60,8 @@ the report folder. These are unrelated to the reports covered in this tutorial a
 :ref:`another advanced topic <howto/rdtraining/K_dashboard>`. For now you can think of them as customized views
 that use direct SQL queries (sometimes referred to as SQL Views).
 
-Don't forget to add whatever files your template and action view will be located in to your ``__manifest__.py``.
-In this case you will want to add the files to the ``data`` list and remember that the files listed in a manifest
+Don't forget to add whatever files your template and action view will be into to your ``__manifest__.py``.
+In this case, you will want to add the files to the ``data`` list and remember that the files listed in a manifest
 are loaded sequentially!
 
 Basic Report
@@ -153,10 +153,10 @@ our minimal property offers template file:
 Most of the Odoo specific (i.e. non-HTML) items in our file are explained in the minimal viable template section.
 Some additional features in our template are:
 
-* The use of the ``class="table"`` attribute so our table has some nice formatting. Twitter Bootstrap
-  (we're using its table class in this case) and FontAwesome (useful for adding icons) classes can
+* The use of the ``class="table"`` attribute, so our table has some nice formatting. Twitter Bootstrap
+  (we're using its table class in this case), and Font Awesome (useful for adding icons) classes can
   be used in your report template.
-* The use of ``t-set``, ``t-value``, ``t-foreach`` and ``t-as`` so that we can loop over all of the ``offer_ids``.
+* The use of ``t-set``, ``t-value``, ``t-foreach``, and ``t-as`` so that we can loop over all the ``offer_ids``.
 
 If you are already familiar with website templating engines, then the QWeb directives (i.e. the `t-` commands)
 probably don't need much explanation and you can just look at its :ref:`documentation <reference/qweb>` and
@@ -170,7 +170,7 @@ such as setting and accessing temporary variables. For example, in the above exa
 
 * ``t-set`` creates a temporary variable called "offers" that has its value set by ``t-value`` to the current
   ``estate.property`` recordset's ``offer_ids``.
-* the ``t-foreach`` and ``t-as`` usage is the equivalent to the Python:
+* The ``t-foreach`` and ``t-as`` usage is the equivalent to the Python:
 
 .. code-block:: Python
 
@@ -187,9 +187,9 @@ corresponding to
 Its contents are all explained in :ref:`the documentation <reference/actions/report>`.
 
 An ``ir.actions.report`` is primarily used via the Print menu of a model's view. In the practical
-example, the ``binding_model_id`` specifies which model's views the report should show in and Odoo
+example, the ``binding_model_id`` specifies which model's views the report should show, and Odoo
 will auto-magically add it for you. Another common use case of the report action is to link it to
-a button like we learned in :ref:`howto/rdtraining/10_actions`. This is handy for reports that
+a button as we learned in :ref:`howto/rdtraining/10_actions`. This is handy for reports that
 only make sense under specific conditions. For example, if we wanted to make a "Final Sale" report,
 then we can link it to a "Print Sale Info" button that appears in the form view only when the
 property is "Sold".
@@ -199,7 +199,7 @@ property is "Sold".
     :alt: Print Menu Button
 
 You may have noticed or are wondered why our report template loops through a recordset. When our
-template is passed more than one record, it can produce one PDF report for all of the records.
+template is passed more than one record, it can produce one PDF report for all the records.
 Using the Print menu in the list view with multiple records selected will demonstrate this.
 
 Make a Report
@@ -233,7 +233,7 @@ Sub-templates
       :alt: Report using a subtemplate
 
 There are two main reasons for using sub-templates. One is to make the code easier to read when working with
-extra long or complicated templates. The other is to reuse code where possible. Our simple property offers
+extra-long or complicated templates. The other is to reuse code where possible. Our simple property offers
 report is useful, but listing property offers information can be useful for more than just one report template.
 One example is a report that lists all of a salesman's properties' offers.
 
@@ -286,7 +286,7 @@ created for them, so we can add this information to our report.
 Additional Features
 ===================
 
-All of the following extra features are described further in the :ref:`reference/reports/report`
+All the following extra features are described further in the :ref:`reference/reports/report`
 documentation, including how to implement each of them.
 
 Translations
@@ -294,13 +294,13 @@ Translations
 
 We all know Odoo is used in multiple languages thanks to automated and manual translating. QWeb reports are no
 exception! Note that sometimes the translations do not work properly if there are unnecessary spaces in your
-template's text content so try to avoid them when possible (especially leading spaces).
+template's text content, so try to avoid them when possible (especially leading spaces).
 
 Reports are web pages
 ---------------------
 
 You probably are tired of hearing that QWeb creates HTML, but we're saying it again! One of the
-neat features about reports being written in QWeb is they can be viewed within the web browser.
+neat features of reports being written in QWeb is they can be viewed within the web browser.
 This can be useful if you want to embed a hyperlink that leads to a specific report. Note that
 the usual security checks will still apply to prevent unauthorized users from accessing the reports.