[DOC] docsource: brand-consistency caps fixes

docsource/010_introduction.rst

@@ -30,7 +30,7 @@ and that the OpenUpgrade logo includes the ant present in the *OpenERP* logo.
 Migration from one version to the next
 --------------------------------------
 
-In the following, **Openupgrade X** will be understood as the tool used
+In the following, **OpenUpgrade X** will be understood as the tool used
 to migrate a database **from version X-1 to version X**.
 For example, if you want to migrate from version 14.0 to 15.0:
 
@@ -46,17 +46,17 @@ should perform two Upgrades via OpenUpgrade 15.0, then OpenUpgrade 16.0:
 
 .. image:: images/migration-14-16.png
 
-Openupgrade design
+OpenUpgrade design
 ------------------
 
-* From Openupgrade 5.0 to Openupgrade 13.0, the branches
+* From OpenUpgrade 5.0 to OpenUpgrade 13.0, the branches
   in https://github.com/OCA/OpenUpgrade contain copies (or forks in Git terminology)
   of the Odoo main project, but with extra commits that include the framework,
   and the analysis and the migration scripts for each module.
 
-* Since Openupgrade 14.0, the branches contain
+* Since OpenUpgrade 14.0, the branches contain
 
-    * a module ``openupgrade_framework`` which brings together all the patches of odoo
+    * a module ``openupgrade_framework`` which brings together all the patches of Odoo
     * a module named ``openupgrade_scripts`` which contains analysis and migration scripts.
 
 Why migrate to a more recent major version
@@ -91,7 +91,7 @@ In short, not migrating your Odoo instance to a recent version means increasing
 
 For more information, see `OCA presentations <https://www.youtube.com/watch?v=WF-BaukCGPs&list=PLRaJ_rIFxm3t6nLStE89Selv597xgvybW>`_ on the benefits of migration and how to manage upgrades.
 
-Alternative to Openupgrade
+Alternative to OpenUpgrade
 --------------------------
 
 To migrate from one major version to another, there are alternatives to using OpenUpgrade :

docsource/020_required_knowledge.rst

@@ -1,13 +1,13 @@
 Required Knowledge
 ==================
 
-To Use Openupgrade
+To Use OpenUpgrade
 ------------------
 
 * you should be able to launch an instance of Odoo on your local PC,
   or on your server, **for each version of your migration**.
 * You should know how to get `openupgradelib`, obtained from the source repository, installed in your Python environment that is going to run the instance.
-* You should know how to invoke the odoo executable, injecting arguments for loading server wide modules and migrations path.
+* You should know how to invoke the Odoo executable, injecting arguments for loading server wide modules and migrations path.
   For example, if you're migrating from version 12.0 to 16.0,
   you should be able to launch Odoo versions 13.0, 14.0, 15.0 and 16.0.
 
@@ -17,7 +17,7 @@ To Use Openupgrade
   In this case, using the `gitaggregate <https://pypi.org/project/git-aggregator>`_
   tool greatly facilitates the management of these numerous pull requests.
 
-To develop Openupgrade Scripts
+To develop OpenUpgrade Scripts
 ------------------------------
 
 - If you want to develop migration scripts for a given module, you need to have

docsource/070_migration_files.rst

@@ -1,7 +1,7 @@
 Migration Files
 ===============
 
-For each odoo module, a **migration directory** contains the analysis of
+For each Odoo module, a **migration directory** contains the analysis of
 the differences between the previous version and the current version
 and the migration scripts developed to ensure the migration
 of this module runs properly.
@@ -94,9 +94,9 @@ The change description flags the following types of change:
 
     * The field is now required. The upgrade script might apply the default for
       this field, if it is encoded in the model, or any value that you might see
-      fit (see the openupgrade library
+      fit (see the OpenUpgrade library
       function :meth:`~openupgrade.set_defaults`). If any empty values remain,
-      these can be reported by the openupgrade report module (TODO).
+      these can be reported by the OpenUpgrade report module (TODO).
       If the field is a function field after the upgrade, this changes the cause
       for action. See below.
 

docsource/080_migration_script_development.rst

@@ -98,7 +98,7 @@ Basically, this is the happening during the step when you try to run the upgrade
 described in :doc:`040_run_migration`:
 
 - [A] get the copy of your database in old version as `db-upgrade`, it is
-  easy to do through the database manager of your old odoo
+  easy to do through the database manager of your old Odoo
   `http://localhost:8069/web/database/manager`
 - [B] run ``odoo -d db-upgrade -u all --stop-after-init``
 - [C] In case of error, fix the error adding or editing migration