Some languages aren't available on Transifex for saas versions if we do not have a dedicated maintainer for the language or not enough of the language is translated, but they are available for major versoins. As of the time of this commit this included:

- Azerbaijani (az),
- Bulgarian (bg),
- Croatian (hr),
- Estonian (et),
- Greek (el),
- Hebrew (he),
- Hungarian (hu),
- Latvian (lv),
- Mongolian (mn),
- Persian (fa),
- Portuguese (pt),
- Romanian (ro),
- Slovak (sk),
- Slovenian (sl),
- Ukranian (uk)

Therefore this commit pulls the current translations from the 18.0 transifex project for these languages. Note that pot file msgmerges were not applied since the end result would have been the same, missing terms from pot files won't have a translation in the po file + extra terms in the po file not in the pot won't be used.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to reproduce:
- Go to Expenses > Expense Reports
- Make sure that no expenses are present to make the sample data display
- Try clicking on the left panel to change the filter on the status
- It doesn't work

### Cause:
The display of sample data adds the class "o_view_sample_data" to the `Layout` component containing the control panel, the search panel and the list ([see](https://github.com/odoo/odoo/blob/e1b6f55840c9d5e2c0f6705add8d82a311fb04a7/addons/web/static/src/views/list/list_controller.xml#L6)). When this class is added, the events are ignored for div with `form-check` ([see](https://github.com/odoo/odoo/blob/e1b6f55840c9d5e2c0f6705add8d82a311fb04a7/addons/web/static/src/views/view.scss#L7-L10)) As the `SearchPanel` component is inside the `Layout` component and contains form-check for the filters on Selection fields (state for example), this filter also gets deactivated.

### Solution:
Add the class `o_view_sample_data` in the Renderer and not the Controller component, this way we make sure that only the interactions with the sample data get deactivated. Doing this implies adding a prop in the Renderer to pass the value of `useSampleModel` to the renderer.

Fix done for the list and kanban view which are problematic with the Expense Reports page.

opw-4707016

Forward-Port-Of: odoo/odoo#208003
Forward-Port-Of: odoo/odoo#206060

Versions
--------
- 17.0+

Steps
-----
1. Create a product with 3 attributes;
2. add a never-create multi-select attribute;
3. archive the first two variants;
4. publish the product to eCommerce;
5. open /shop.

Issue
-----
> 500: Internal Server Error

Cause
-----
Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination.

Issue is when continuing after the `yield`, it attempts to get the `current_ptav_index` from the `current_line_values` recordset, which is empty for `multi`-type attributes. This causes an `IndexError`.

Solution
--------
Only assign the `current_ptav` variable if `current_line_values` is not falsey, i.e. isn't on a `multi` attribute line.

Because `current_ptav_index` will always be `-1` in this scenario, it will skip over the conditional branches where `current_ptav` gets used, and instead go to either `continue` or `break`.

opw-4653696

Forward-Port-Of: odoo/odoo#203093

**Problem:**
The problem happens when  a service is linked to a task but it's not billed on timesheet.

If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation.

If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. 

Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation.

**Steps to reproduce:**
- In settings, activate the "margins" setting in Sales
- Open Sales/products and create a new product
- Set the product type as "Service"
- Set the "create on order" field as Task
- Set the "project" field to an existing project
- Set a strictly positive value in the cost field
- Set a name and save
- Create a new quotation and add the product you just created
- Confirm the quotation
- In the order lines page, add the cost column
- Change the value of the cost column
- Click on the "Tasks" smart button
- Add a new timesheet in the timesheet page and save
- Come back to the sale order via the smart button

**Current behavior:**
The value of the cost column was reset the the cost of the product

**Expected behavior:**
Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets

**Cause of the issue:**
Because the sale_timesheet_margin module is installed the
_compute_purchase_price method is overriden and depends on
analytic_line_ids.amount
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8
when this method is called in our flow, because
sol.product_id.purchase_price is not null our sale order line
will not get filtered out
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11
and it will reach the original
_compute_purchase_price method were the value of purchase_price
will be reset to the value of self.product_id.standard_price
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30


**Fix:**
We want to filter out the sale.order.lines for which the computation
of purchase_price has been triggered via the analytic_line_ids.amount
dependency and for which we don't want the computation to happen
(when the service_policy is not "timesheet").
We need to do this without filtering out the sales.order.lines for which the
computation of purchase_price has been triggered by a dependency from
the original compute_purchase_price method
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21
or another orverride of this method
(for now there are two of those : one in sale_expense_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11
and one in sale_stock_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11
)

is_expense is defined in the sale module
is_service is defined in the sale_service module
service_policy is defined in the sale_project module
all those field are available when sale_timesheet_margin is installed



opw-4627037

Forward-Port-Of: odoo/odoo#205415

When using an intermediate return location, the delivered qty of a 
returned kit is incorrect

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a location L:
   - Parent: WH
   - Type: Internal
   - Return location: True
3. Create a route:
   - Applicable on: Main warehouse
   - Add one rule:
     - Action: Push To
     - Operation Type: Internal
     - From: L
     - To: WH/Stock
4. Create a kit K
5. Sell and deliver 1 x K
6. Return it to L
   - It will create an internal transfer 
7. Process the internal transfer
8. Open the SO

Error: The delivered quantity of the kit is -1 instead of 0

Step 6, when returning the kit, the push rule is applied and create 
the SM from L to WH/Stock. Since we copy the SM from Customer to L, the
new SM also has the field `sale_line_id` defined.

As a result, step 7, since all SM are done, `moves` contain them 
(the delivery, the return and the internal transfer). We then filter 
them based on some criteria:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L67-L73
But, for `outgoing_moves` (which is actually the incoming ones, the 
name is wrong), since we look at the destination location, both the 
return and the internal SM will match. That's why we will decrease 
twice the delivered quantity. Hence, the bug.

A fix could be to avoid copying the `sale_line_id` field. That being 
said, when looking `sale_stock` side (i.e., same flow with a classic 
product), we don't have any issue because the filters are slightly 
different:
https://github.com/odoo/odoo/blob/418dc0cc3b3aa1ee2abbdb4852d9cd24fba7636e/addons/sale_stock/models/sale_order_line.py#L274-L278
(Here, we need to look at the `incoming_moves`. Again: the name is just 
incorrect on mrp side...)
We see that, for `incoming_moves`, we actually look at the source 
location. This explains why we don't have any issue with a non-kit 
product.

Therefore, the best fix would be to use the same filters everywhere. 
Good news, such a method already exist:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L115-L116
However, using this method might lead to some other issues (among them: 
the override in `sale_subscription_stock` reads a field although the 
method is an `api.model` one). So, let's minimize the diff on stable 
version and refactor the code (use the same filters everywhere) on 
master.

About the filter names, the confusion actually comes from:
https://github.com/odoo/odoo/blob/312572c7b8138a4800350cd7a524a37551a348ef/addons/mrp/models/stock_move.py#L624
There, we should rather talk about positive moves and negatives 
moves, since this method can be used either in a SO flow or in a PO 
one. This explains why, for now, SO sode, an "incoming move" is 
actually an outgoing one. So, on master, another commit will be 
added to also clean that part of the code:
\- Improve the expected filter names in `_compute_kit_quantities`
\- Fix the filter names in `_get_incoming_outgoing_moves_filter`

OPW-4625228

Forward-Port-Of: odoo/odoo#207739
Forward-Port-Of: odoo/odoo#206966

Steps to reproduce the bug:

- Use Edge browser with zoom set to 150% (default zoom on Windows installations).
- On a screen with a resolution of 1920px (and the browser window set to full width).
- Install the Website app and go to the homepage.
- The page is displayed in desktop view.
- Enter edit mode by clicking the "Edit" button.
- The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the layout changes to mobile style.

This should not happen, as the edit mode is designed to remain in desktop view with 150% zoom on 1920px wide screens. The issue is caused by Edge adding a few pixels of border around the browser window, which leads to this problem specific to Edge.

To fix this in the stable version, we reduce the sidebar width in edit mode by 5 pixels to ensure the page stays in desktop view. This change is applied only if the browser is Edge and 150% zoom is used. In all other cases, no changes are made.

This fix is temporary. In the next redesign of the edit mode sidebar, the sidebar width will be adjusted accordingly so that this workaround will no longer be necessary.

Note: The Arc browser has the same issue, but we haven’t fixed it because there’s currently no way to reliably detect it in JavaScript. Since Arc is much less popular than Edge, it’s less critical.

task-4587203

Forward-Port-Of: odoo/odoo#207835
Forward-Port-Of: odoo/odoo#205721