## Version:
saas-18.0+

## Issue:
Importing eCommerce translations for products erase all existing translations and set the new one as default value, whatever the user's current language is.
The `website_description` acts the same.

## Steps to reproduce:
- From the user's `Preferences`:
  - Add a second language you understand;
  - Translate all websites and close without switching;
- Access `Sales / Products / Products`:
  - Set a product as favorite and open it:
    - Under the `Sales` tab, write something in the `ECOMMERCE DESCRIPTION` field;
    - Open the translation wizard by clicking the `EN` link appearing when hovering the input:
      - Write anything else in the second language's input field and save;
- Come back to the general products view (*`Sales / Products / Products`*):
  - Change view to list and select the favorite item (*check the case of the record line*);
  - Via the `Actions` button, click on `Export`:
    - Check `I want to update data (import-compatible export)`;
    - From the `Available fields` list, add `eCommerce Description`;
- Open the exported file:
  - Change the `description_ecommerce` content and save;
- From the general products view (*`Sales / Products / Products`*):
  - Ensure no product is selected;
  - Click the gear next to `Products` then `Import records`
    - Click `Upload Data File` and select the exported and modified file;
    - Ensure the fields are well mapped;
    - Test then import data;

## Cause:
Translation method refactoring via this PR: https://github.com/odoo/odoo/pull/170779, especially `update_field_translations(field_name, {"fr_FR": {"en2": "fr2"}})`, requiring a key (`en2`) and a value (`fr2`) for a given language as a `field_name` translation. Before the fix, giving only one value erases value and key for a given `field_name`

opw-4600662

Steps to reproduce the bug:
- Create a storable product “P1”:
    - Update the quantity to 1 in "WH/Stock"
    - Create a putaway rule:
        - From "WH/Stock" to "WH/Stock/Shelf1"

- Create a manufacturing order:
    - Select any product to produce
    - Add a component:
        - 1 unit of P1

- Confirm and validate the MO
- Unbuild the order

Problem:
A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not called on the `stock.move.line` linked to the move.

In previous versions (e.g., v17), this issue didn't occur because the quantity was directly set on the move. This triggered a write on the `stock.move` model, which in turn called `_set_quantity`. Since no `stock.move.line` was linked at that point, a new one was created, and its quantity was set via `_set_quantity_done`, which itself called `_apply_putaway_strategy`:

- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133

This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186

However, starting from v18, some code was refactored to clean up unnecessary conditions. The `else` block was removed, and now, regardless of the product type, the quantity is not set directly on the move anymore. Instead, a `stock.move.line` is created using `_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197

But `_apply_putaway_strategy` is not called in this flow.

Bug introduced in v18.0, commit:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be

opw-4830952

# Issue:
When sending an email with an attachment to an incoming alias, if the target folder in Documents is explicitly owned by a specific company, an error occurs during alias creation: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany while the owner document belongs to company Company2."

This issue arises because the `mail.alias.mixin.optional` model, when determining the `company_id` for the alias associated with the new document, might default to the system's company or another incorrect company, leading to a mismatch with the actual company of the explicitly-owned document folder.

# Proposed solution:
This commit modifies the `create` method of `mail.alias.mixin.optional` to prioritize the `company_id` of the document's target folder when setting the `company_id` for the associated alias.

Specifically, within the loop where alias values are prepared:
- It first attempts to retrieve the `company_id` directly from the `vals` dictionary for the current record.
- If no `company_id` is explicitly provided in `vals` but a `folder_id` is present, it then checks the `company_id` of that `documents.folder`.
- If the folder has an explicit `company_id`, this company is used as the effective `company_id` for the alias.
- Otherwise, it falls back to the previously determined `company_id_default`.

This ensures that the `company_id` used for alias domain validation aligns with the `company_id` of the document's folder, resolving the domain/owner company mismatch error.

opw-4727873


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