Bug 123318

(In reply to Mike Kaganski from comment #0)
> Since 6.2 released, opening generic https://help.libreoffice.org opens a
> page in Writer module [1], which has "Search in chosen module" active. That
> makes that generic address not suitable to search in other modules without
> explicit switch.

This isn't true. It opens it in shared module, with "Search in all modules" active.

There is also bug 122366, which would further alter the behaviour.

(In reply to Buovjaga from comment #1)

You are right; must had been some problem with browser cache (or some other problem I could invent to find excuses).

So only #2 and #3 from comment 0 are valid here.

This enhancement has been in UNCONFIRMED status for a while, moving it to NEW...

(In reply to Mike Kaganski from comment #0)
> 3. Add an easy way to switch between "Search in chosen module" and "Search
> in all modules".

Olivier: I can easily add and entry to help2.js's setupModules like so

'<a href="' + lang + '/text/shared/05/new_help.html?DbPAR=SHARED">All</a>'

But how could we deal with localising this string?

Entering the main page in LO 7.4 leads to:
https://help.libreoffice.org/7.4/en-US/text/shared/05/new_help.html?&DbPAR=WRITER&System=UNIX

Which is by default formatted as a Writer help page, but the search box says "Search in all modules".

Up until LO 7.2 this box indeed searched all modules by default. However, since commit [1] search results only show the current module and Global results (instead of all modules). This commit is effective since LO 7.3.

[1] 8b955ca1d2fa8132a22be12daeb416618277905c (https://gerrit.libreoffice.org/c/help/+/122903)

To search a different module (7.3 and onwards) the user has to manually switch to it using the "Modules" drop-down list.

I could not find any way to effectively search in all modules. I believe we need an easier way to switch between "Search in all modules" and "Search in module XXX".

My suggestion is:
1) Create an option in the Modules list named "All modules"
2) Make this the default option when the user arrives from the generic help page https://help.libreoffice.org

Sure, Rafael, and it is not difficult. Now that I think about it again, I guess we would have to sacrifice the avoidance of repetition that setupModules JS function provides and include the module links in every generated HTML page. I assume this is the only way we can localise the text "All". Or should we inject the help2.js JavaScript into XSLT and provide localisation through it for this single string?

(In reply to Buovjaga from comment #6)
> Sure, Rafael, and it is not difficult. Now that I think about it again, I
> guess we would have to sacrifice the avoidance of repetition that
> setupModules JS function provides and include the module links in every
> generated HTML page.

How about add the following entry to setupModules:

<a href="' + lang + '/text/shared/05/new_help.html"><div class="all-icon"></div>All</a>

This would land in the Shared home page without any DbPAR, causing all modules to be searched.

Of course the class "all-icon" would have to be defined (maybe the standard LibO doc logo, the white one at the top of [1])

[1] https://wiki.documentfoundation.org/images/thumb/6/65/LibreOffice_icons_256.png/600px-LibreOffice_icons_256.png

(In reply to Rafael Lima from comment #7)
> (In reply to Buovjaga from comment #6)
> > Sure, Rafael, and it is not difficult. Now that I think about it again, I
> > guess we would have to sacrifice the avoidance of repetition that
> > setupModules JS function provides and include the module links in every
> > generated HTML page.
> 
> How about add the following entry to setupModules:
> 
> <a href="' + lang + '/text/shared/05/new_help.html"><div
> class="all-icon"></div>All</a>
> 
> This would land in the Shared home page without any DbPAR, causing all
> modules to be searched.

Yes, that is what I said a month ago in comment 4, but localisation is the problem. That is why in comment 6 I proposed to get rid of the JavaScript for creating these links on the fly.

(In reply to Buovjaga from comment #8)
> Yes, that is what I said a month ago in comment 4, but localisation is the
> problem. That is why in comment 6 I proposed to get rid of the JavaScript
> for creating these links on the fly.

Now I understand it... the problem is with translating specifically the string "All".

Maybe we could use something else that does not need translating, such as "LibreOffice" instead of "All".

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/eb1bf86ac137d050daaaed114a70c29002acc4fe

tdf#123318 Add navigation menu entry LibreOffice for Shared

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/143eb86de536e863170222617485c3e7f41d628a

Related tdf#123318 Fix filtering with SHARED

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/21f7faaea2017e085b030d4c40c24067e37a1ee5

Related tdf#123318 Fix harder and update Base URL path

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/919def267b89cfe03f40218baa8c16cf65526448

tdf#123318 tdf#129697 Don't hardcode product name in CSS and JS

(In reply to Mike Kaganski from comment #0)
> 2. Make necessary corrections to its metadata to move it to common topics in
> Contents;

This is still not done for source/text/shared/main0108.xhp but I don't know what I should do. I dug around just now and didn't learn anything.

(In reply to Buovjaga from comment #1)
> (In reply to Mike Kaganski from comment #0)
> > Since 6.2 released, opening generic https://help.libreoffice.org opens a
> > page in Writer module [1], which has "Search in chosen module" active. That
> > makes that generic address not suitable to search in other modules without
> > explicit switch.
> 
> This isn't true. It opens it in shared module, with "Search in all modules"
> active.
> 
> There is also bug 122366, which would further alter the behaviour.

Hmm. It seems that my #1 was just filed ahead of time. I should had not used my time machine, to not uncover myself ;)

So now with 7.3, I do see that https://help.libreoffice.org/ goes to Writer's module (it redirects to https://help.libreoffice.org/latest/en-US/text/shared/05/new_help.html?&DbPAR=WRITER&System=WIN), and typing anything in search that doesn't belong to Writer does not give results, until I remove the automatically added "?&DbPAR=WRITER&System=WIN" from the address (of course, the "DbPAR=WRITER" is actually harmful here). And switching to another module using the site menu (so that the other module is used in the query) does not get "saved" across sessions, so the next time I use the initial URL, it redirects to Writer again.

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/3e86799f1b1e957e442a23022bc12cc25bb0c8a6

tdf#123318 Use SHARED as the default module instead of WRITER

Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/help/commit/0f12f8a4dcf3b3ee34864d50f06e77d495fb9133

tdf#123318 Use SHARED as the default module instead of WRITER

Mike: yesterday you mentioned in the chat that the Shared/LibreOffice module selection still does not allow searching through all the index entries. However, this is only the case with 7.3. If you test with 7.4 Help, it works as we would expect: https://help.libreoffice.org/7.4/en-US/text/shared/05/new_help.html?DbPAR=SHARED

So I guess we could close as fixed.

(In reply to Buovjaga from comment #18)

I agree; thank you!