Inform user of known long-term export problems for specific languages

[PeterNerlich]

Motivation

The export for a few languages (including but not limited to right-to-left languages, see #2020/#2021/#2022/#2385, #2870 as well as #1498) is defective and will not be able to be fixed anytime soon for technical reasons. This might pose a pitfall for users of the system, who should generally be able to expect the system to either work as intended or be fixed in due time.

Proposed Solution

Add a notice when the user is about to export a page to a language where problems are known (that won't be resolved any time soon). Optionally decline to complete the action altogether.

Alternatives

• Continue leaving it to the user to stumble across export problems, likely in situations where they are depending on it and where the problem becomes apparent on second or third glance only. This can mean high stress for the person who thought they got help, frustration, additional work and loss of trust for the user of our system as well as a continued baseline of load for the service team.

User Story

As a user, I prefer to be notified of problem areas within the system beforehand so I can work around them to finding out something went wrong after the fact.

Additional Context

It is to be discussed with the service team whether this desirable and to be implemented.

Design Requirements

Proposed to take the form of simple warning messages within the existing message system, which would not require additional design.

[MizukiTemma]

Conclusion after the discussion:

• Deactivate the PDF bulk action for all languages that have any problem in export.
• If deactivated, add tool tip message "Currently the PDF-Export in this language is not available."

[david-venhoff]

Most problems are caused by the xhtml2pdf library right?
If so, we could also go for an intermediate solution and redirect the user to the html page that we would normally feed into xhtml2pdf instead. Then we could use some js like window.print() to use the browsers built-in export to pdf functionality.
Disadvantages would be that the user experience would be a bit worse and that there are probably slight differences how different browsers convert html to pdf.
Advantage would be that we would have working export and could be pretty sure that the browser handles all languages correctly.
For the ui, we could also show a warning that normal export does not work and offer this as an alternative.

@PeterNerlich @MizukiTemma Do you think something like this could be useful?

Here is a proof of concept:

[MizukiTemma]

@david-venhoff
Hmm, technically it should work and provide a temporary solution, but I'm not sure if it is "intuitiv" for users, especially when the existing export bulk action is working for some languages, while they have to use the new procedure for other languages 🤔

What do you think @osmers @nassabay @dkehne ?

[osmers]

I'd have to see it in action to be able to say if it's confusing for users or not...bcs I cannot imagine right now what it looks like

[dkehne]

how is table of content then generated/visualised and how is the formatting? Is there a chance to generate the whole munich app as pdf as an example?

We use the print to pdf feature in the entitlement card project but i am not convincend that it is a suitable choice here.

Do we only use this Browser-Printed-PDFs for RTL or all languages?

[MizukiTemma]

@dkehne

The browser-printed-PDF is only thought for RTL languages (So I understood).

I guess we have to implement our own function to produce table of content for browser-printed-PDF, and probably this will have such difficulties like xhtml2pdf repository 🤔