The self-ordering kiosk does not correctly display translations for product names and other UI elements when switching languages. Some elements remain in English or the database language, even when translations are available.  

### Steps to Reproduce  

1. Open **Point of Sale** and navigate to **Configuration > Settings**.  
2. Select a POS configuration that has **Kiosk/Self-ordering** enabled.  
3. Add additional languages to the Kiosk and save the changes.  
4. Open a product available in the Kiosk POS and add translations for its name.  
5. Start a new Kiosk session, switch to the Kiosk window, and change the language.  
6. Notice that product names and other UI elements remain in English instead of switching to the selected language.  

### Cause  

- The `/pos-self/data/<config_id>` route was missing `website=True`, preventing it from receiving the correct frontend language setting.  
- Adding `website=True` fixes this issue, allowing the POS frontend to receive the correct language.  

### Secondary Issue

- After adding `website=True`, another problem emerged when the **website module** is installed.  
- In this case, the available languages were taken from the **website settings** instead of the **POS settings**.  
- This means that if the website only supports English but the POS Kiosk supports both English and French, switching the Kiosk language to French would fail. The system would always revert to English because language validation was still based on website settings rather than POS settings.  

### Solution  

1. **Fix the original issue** by adding `website=True` to ensure the POS self-ordering system receives the correct language.  
2. **Work around the secondary issue** by checking the **Referer** header to determine if the request comes from a POS self-ordering session.  
3. **Ensure language validation is based on POS settings**, not website settings, by retrieving available languages from the POS configuration when necessary.  

This solution follows a similar approach to the fix in **cd69a32503f4dcd11851908e2c983e1d49a1c2a8**, but in this case, the problematic route (`/website/translations`) is not strictly POS-related. Therefore, we must check the referer to extract the correct POS information.


opw-4557569
opw-4471819
opw-4436306

Forward-Port-Of: odoo/odoo#201594

During post-install tests, run the following code in a python terminal:

    import socket, time
    with socket.create_connection(('127.0.0.1', 8069)):
        time.sleep(6)

It opens a socket and connect to the running odoo server, but does nothing. After 5 seconds the odoo server closes the socket with a timeout.

The timeout is only set during tests in ``RequestHandler.setup``, and it set to a hardcoded value of 5 seconds. Since Werkzeug 2.1.0[^1], it logs an error in the logs. We want to get rid of that error log.

Those errors can occur when the test chrome browser is killed while it was performing http requests. Chrome doesn't TCP RST the sockets and just let those sockets die.

The socket timeout error actually cannot occurs in production, as all traffic is routed via nginx, and nginx will only proxy the connection to Odoo once nginx has all the requests headers.

That error log is silly, it is now ignored.

[^1]: pallets/werkzeug:d062807

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

Forward-Port-Of: odoo/odoo#203757