In the current implementation, updating translations for a `blog.post`
via the route
`/web/dataset/call_kw/blog.post/web_update_field_translations`
fails to apply changes when the post has already been translated once.
This issue is caused by how the system fetches `website.default_lang_id`
from the request.

__Current behavior before commit:__
When editing a previously translated field for `blog.post` or
`product.template`, the system retrieves the website from the request to
determine the `source_lang`. This is used to search for the original
term in the source language and update its translation. However, due to
the `website=True` parameter not being set for the controller,the system
defaults to English (`source_lang = 'en_US'`). As a result:

1. The system searches for the original word in English, even if it
exists in another language.
2. The translation update fails because the original word cannot be
found in English.

__Description of the fix:__
A new controller was introduced to specifically handle translation
updates, ensuring the correct language is fetched and the translation
logic is applied correctly.

__Steps to reproduce the issue:__
1. Add 2 or more languages to the website.
2. Set the default language to any language other than English (US).
3. Create a blog post and write text in the default language.
4. Switch to another language, translate the text and save.
5. Edit the translated text again.
The last edits are not saved.

- bug introduced in: [#06346b0][1]
- opw-4239512

[1]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e

Forward-Port-Of: odoo/odoo#195794
Forward-Port-Of: odoo/odoo#184415

### Issue:

Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records.

### Note:

This is easily reproducible by hand in localhost and should worsen if you have server delay. In addition, it makes it impossible to write a proper tour involving the catalog in the shopfloor.

### Steps to reproduce:

- Create a product with a bom and an operation op1
- Create and confirm an MO for 1 unit of that product
- Go to the shopfloor > on the operation > wheel > Add component
- Add a component to be consumed in that operation
- Close the catalog fast (using ESC for instance)

#### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor.

### Cause of the issue:

When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed.

### Fix:

We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved.

#### To be more precise:

The `ProductCatalogKanbanController` component contains a list of promises (initially empty): `catalogKanbanUpdates` aswell as an optional callback props `onCatalogUpdated`. This list is going to be populated each time that a `ProductCatalogKanbanRecord` make a quantity update (used stock moves on the mrp.production). To populate this array of promises a method is defined in the controller: `pushCatalogKanbanUpdate`. This method needs to be called by the `KanbanRecords` an hence is transported using xpath from the `ProductCatalogKanbanController` to the `ProductCatalogKanbanRecord` via the `ProductCatalogKanbanRenderer`. Once the controller is detroyed (and hence each kanban record that had to update a quantity started its call) if a callback was given to the props of the Kanban controller we wait for all the update promises to be resolved and we call that call back.

opw-4199156
---

Forward-Port-Of: odoo/enterprise#79190
Forward-Port-Of: odoo/enterprise#74151