Help pages like [1] have alternative content that depends on the OS. For Windows, it shows one text in "Managing your Certificates"; for Linux, another. The hidden text is completely inaccessible on the help page (unless you read the source). This makes one to see very different content based on what is used to access the page. This is a problem e.g. when helping others; or when using different device (like one's phone) to read help in case of inaccessible Internet. The suggestion is to allow one to read all the alternatives, just collapse the text for other OSes by default. [1] https://help.libreoffice.org/7.0/en-US/text/shared/guide/digitalsign_send.html
(In reply to Mike Kaganski from comment #0) > The hidden text is completely inaccessible on the help page (unless you read > the source). Or manually change relevant part of URL: WIN <--> MAC <--> UNIX
(In reply to sdc.blanco from comment #1) > Or manually change relevant part of URL: WIN <--> MAC <--> UNIX :-) please look at the URL mentioned in comment 0 - there's no "relevant part" there. I suppose that your comment is for completeness (because it is nice to know the trick, but of course not something that makes it easy for a user looking at the help on own Android trying to fix something for Windows :-))
The page can display the OS relevant part, by adding the System=[WIN|MAC|UNIX] param in the URL, e.g. https://help.libreoffice.org/7.0/en-US/text/shared/guide/digitalsign_send.html?System=WIN The default display depends on the <default> tag contents. Displaying all <switch> contents can disrupt the reading, especially with <switchinline>. Another approach is to let user select (override?) the proper OS thru a widget on the page (e.g. dropdown list or radio buttons, valid only for the online Help).
(In reply to Olivier Hallot from comment #3) > Another approach is to let user select (override?) the > proper OS thru a widget on the page (e.g. dropdown list or radio buttons, > valid only for the online Help). That would be fine! :-)
(In reply to Olivier Hallot from comment #3) > Displaying all <switch> contents can disrupt the reading, especially with > <switchinline>. However, having a superscripted "WIN" after the alternate content, with some drop-down selector with list of available choice OSes, and the affected text changed dynamically accordingly, could also be non-disrupting variant (no idea if it's easy to implement ...) - that would visually resemble the Wiki's visual appearance when it contains a reference to another language's article, but with in-place changing content instead. Something like (^WIN stands for "superscripted WIN"): > ... press Ctrl+Shift+C^WIN ... where clicking on superscripted WIN would give a popup with choices "WIN", "Linux", "macOS", and which would turn into > ... press Cmd+Shift+C^MACOS ... when another choice is made there?
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Olivier Hallot from comment #3) > The page can display the OS relevant part, by adding the > System=[WIN|MAC|UNIX] param in the URL, e.g. > > https://help.libreoffice.org/7.0/en-US/text/shared/guide/digitalsign_send. > html?System=WIN > > The default display depends on the <default> tag contents. > > Displaying all <switch> contents can disrupt the reading, especially with > <switchinline>. Another approach is to let user select (override?) the > proper OS thru a widget on the page (e.g. dropdown list or radio buttons, > valid only for the online Help). We discussed this in the dev chat today. I understand that certain pages like digital signatures have an unusual amount of OS-specific text. In most cases it is about menu item paths, though. I wonder, if we should be concerned about showing too much info. Maybe in the cases like digital sigs, we should think more about in what order we present the sections. In this particular case, the only extra info is for Windows. We could move it to the bottom and have an anchor link to it at the top. The discussion with Mike really made me believe that we could try getting rid of these parameters and just display everything (ie. no widget solutions or anything fancy). Then, if users complain, we can consider what to do. I have a feeling there will be no complaints, if the content is organised in a neat way.
For the context, there was a discussion involving: 1. HTML help not working on systems without major browsers (a user reported the problem with X-via-SSH system with only lynx present); 2. HTML help not working on (some?) macOS; 3. "HTML-help's dynamic generation of HTML files is a pain for the flatpak case" (sberg) (further commented: 'see 72b936d70b7eaa6d9f5f911b27e3c955382de967, "LO can't pass a file URL with query part to xdg-open, so uses a temporary wrapper .html file that redirects to the target URL. But for the flatpak case this wrapper can't be in /tmp [...]"') The dynamic part of our HTML help seems to be causing too much problems, which could bite us more in the future with the trend to sandboxing the local files. Thus removing queries and making more content static and user-controllable in-place (collapsed sections again) could be the first step. (By the way, I find the theming dependent on ?DbPAR= query absolutely wrong, when common pages look as if they belong to a specific app, and you may even colorize a Basic help page to look related to Writer.)
The wiki page appears to still only display documentation based on operating system of the user. There doesn't appear to be an option to view documentation for other operating systems as suggested.