camunda / camunda-bpm-platform

Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.
https://camunda.com/
Apache License 2.0
4.13k stars 1.56k forks source link

In Webapps, HTML lang attribute value is not dynamically set based on the available and requested languages #2667

Open ThorbenLindhauer opened 2 years ago

ThorbenLindhauer commented 2 years ago

This issue was imported from JIRA:

Field Value
JIRA Link CAM-14330
Reporter 9RZRpyO
What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Has restricted visibility comments true

Environment (Required on creation):

Camunda Automation Platform 7.17.0

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

The browser (e.g., Google Chrome) shows a popup that offers to translate the Camunda Webapp, although the right localization of the Webapp is already shown.

<^translation-offer-popup.png>

Steps to reproduce (Required on creation):

  1. Change the language in your browser to any language other than english; make sure english is not defined as the fallback language
  2. Configure any Camunda Webapp to use the previously defined language; make sure english is not defined as a fallback language <1>
  3. Open any Camunda Webapp

Observed Behavior (Required on creation):

Even though the Camunda Webapp is correctly translated, the translation offer popup is shown.

Expected behavior (Required on creation):

The translation offer popup is only shown when the requested browser language and the language of the Camunda Webapp differ.

Root Cause (Required on prioritization):

The HTML lang attribute value is hardcoded to en <2>.

Solution Ideas (Optional):

  1. The user changes the HTML lang attribute value in the index.html to the preferred language
    • Cons:
    • Solution is not reactive to the respective language requested by the client
  2. HTML lang attribute value is changed dynamically client-side (frontend)
    • Cons:
    • This only solves the problem for the screenreader but not for the translation offer popup since it doesn't react to client-side changes
  3. HTML lang attribute is dynamically served server-side (backend) based on the request header Accept-Language
    • Cons:
    • Effort is higher
    • Under some circumstances, the problem still exists:
      • Our localization feature <1> is implemented on the client-side (frontend), which means our backend is not aware if the language the browser requests is actually supported
      • The server might set the language to an unsupported language, but the Webapp is actually translated to a different language
      • As a result, the browser offers to translate from a wrong source language

Hints (optional):

-

Original Ticket Description

The lang attribute of the main HTML tag is always set to "en" even if a different locale is set (fr in my case).

Consequently, some browsers ask users to translate the page, and if the user says yes, some words can be changed.

<1> https://docs.camunda.org/manual/7.17/webapps/cockpit/extend/configuration/#localization <2> https://github.com/camunda/camunda-bpm-platform/blob/bf97f3/webapps/ui/tasklist/client/index.html#L2 **Links:**
ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tasso94


Hi 9RZRpyO,

Thank you for reaching out to us with your problem.

We will have a closer look soon.

Stay tuned!

Best, Tassilo

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tasso94


Hi 9RZRpyO,

Thank you for raising this bug report. I agree that this behavior is unexpected.

Unfortunately, fixing this is not trivial. Would it solve the problem for you by changing the preferred language yourself by editing the index.html file of the respective Webapp?

Best, Tassilo

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user 9RZRpyO

What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.


Hi @Tassilo Weidner ,

Do you have a link to a resource that explains how to embed a custom index.html file ? I am using Camunda with Springboot.

Regards,

Sébastien

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tasso94


Hi 9RZRpyO,

Spring Boot allows overriding Webjar contents.

If you want to override Cockpits index.html file, add an adjusted copy of this file to your Spring Boot project under the following path: src/main/resources/META-INF/resources/webjars/camunda/app/cockpit/

Does this answer your question?

Best, Tassilo

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user 9RZRpyO

What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.


Hi, @Tassilo Weidner ,

I have been able to replace the index.html file by a custom one.

Thanks.

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tasso94


Hi 9RZRpyO,

I'm glad that this alternative solution works for you :)(y)

Best, Tassilo

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tmetzke


Hi 9RZRpyO,

thanks again for creating this bug report.

This is to let you know that we consider this a valid bug report and acknowledge this as rather inconvenient behavior. However, we won't work on fixing this in the near future. If you would like to provide a fix for this, we are happy to receive a contribution to our code repository. Let us know if you would like to work on this yourself, we are happy to provide pointers on where to start.

Best, Tobias

ThorbenLindhauer commented 2 years ago

This comment was imported from JIRA and written by user @tasso94


Solution #3 + introducing a configuration property of available and fallback languages in the backend and restricting to serve only the configured languages would solve the shortcomings of this solution. This comes with the trade-off that it needs to be configured redundantly in the front and backend.