starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Search engine doesn't work in italian from Web UI (maybe other languages besides English) #8350

New issue

Closed

opened 2026-02-21 19:33:50 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-21 19:33:50 -05:00

Owner

Originally created by @giuseppe-dandrea on GitHub (Jan 31, 2019).

Please provide the following information

qBittorrent version and Operating System

qBittorrent v4.1.5
Raspbian 9 stretch
(qbittorrent installed from testing repos)

If on linux, libtorrent and Qt version

libtorrent v1.1.11.0
Qt v5.11.3

What is the problem

The search engine in the WebUI doesn't return any results if the language is Italian, but it works fine in the main client.

What is the expected behavior

Return any results from search plugins

Steps to reproduce

Set language to Italian (didn't test with other languages)
Enable WebUI
Open the WebUI and perform a search
No results are returned.

Extra info(if any)

Looked in the Network tab of the chrome dev tools and it seems that the first request of the search (a POST request to the start endpoint) is performed with translated parameters.

These are the form data in the english version:

pattern=ubuntu&category=all&plugins=all

In the italian version the params are translated, instead of all, something like "Tutte le categorie" and "Tutti i plugins" appears.

Maybe these parameters are not correctly managed in the api.

To avoid this bug set the language to English.

Hope this helps someone.

Originally created by @giuseppe-dandrea on GitHub (Jan 31, 2019). **Please provide the following information** ### qBittorrent version and Operating System qBittorrent v4.1.5 Raspbian 9 stretch (qbittorrent installed from testing repos) ### If on linux, libtorrent and Qt version libtorrent v1.1.11.0 Qt v5.11.3 ### What is the problem The search engine in the WebUI doesn't return any results if the language is Italian, but it works fine in the main client. ### What is the expected behavior Return any results from search plugins ### Steps to reproduce * Set language to Italian (didn't test with other languages) * Enable WebUI * Open the WebUI and perform a search * No results are returned. ### Extra info(if any) Looked in the Network tab of the chrome dev tools and it seems that the first request of the search (a POST request to the `start` endpoint) is performed with translated parameters. These are the form data in the english version: `pattern=ubuntu&category=all&plugins=all` In the italian version the params are translated, instead of `all`, something like "Tutte le categorie" and "Tutti i plugins" appears. Maybe these parameters are not correctly managed in the api. To avoid this bug set the language to English. Hope this helps someone.

deekerman

2026-02-21 19:33:50 -05:00

closed this issue
added the
WebUI

Search engine
labels

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@glassez commented on GitHub (Jan 31, 2019):

@Piccirello, please check it.

@glassez commented on GitHub (Jan 31, 2019): @Piccirello, please check it.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@Piccirello commented on GitHub (Jan 31, 2019):

This is a tricky one. It doesn't appear any GUI strings are translated when the GUI isn't build. Which means all the Web UI translations using the CONTEXT of a GUI class just show in english.

This very likely isn't the entire issue, but it's making it hard for me to test.

@Piccirello commented on GitHub (Jan 31, 2019): This is a tricky one. It doesn't appear any GUI strings are translated when the GUI isn't build. Which means all the Web UI translations using the CONTEXT of a GUI class just show in english. This very likely isn't the entire issue, but it's making it hard for me to test.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@glassez commented on GitHub (Jan 31, 2019):

@Piccirello, I didn't understand your comment. What about GUI translations? WebUI uses independent translations currently. qBittorrent web application has its own translator so it shouldn't be affected by GUI.

Web UI translations using the CONTEXT of a GUI class

It's an issue itself. Now we should have more appropriate contexts in WebUI.

@glassez commented on GitHub (Jan 31, 2019): @Piccirello, I didn't understand your comment. What about GUI translations? WebUI uses independent translations currently. qBittorrent web application has its own translator so it shouldn't be affected by GUI. >Web UI translations using the CONTEXT of a GUI class It's an issue itself. Now we should have more appropriate contexts in WebUI.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@Piccirello commented on GitHub (Feb 1, 2019):

It's an issue itself. Now we should have more appropriate contexts in WebUI.

The current practice for all Web UI translations is to reference the appropriate GUI class with the same text. The only case where we deviate is when the Web UI contains text not contained in the GUI, in which case we use a context of HttpServer.

qBittorrent web application has its own translator so it shouldn't be affected by GUI.

In my quick testing Web UI translations that use the Context of a GUI classes aren't translated when the build is configured with --disable-gui.

@Piccirello commented on GitHub (Feb 1, 2019): > It's an issue itself. Now we should have more appropriate contexts in WebUI. The current practice for all Web UI translations is to reference the appropriate GUI class with the same text. The only case where we deviate is when the Web UI contains text not contained in the GUI, in which case we use a context of `HttpServer`. > qBittorrent web application has its own translator so it shouldn't be affected by GUI. In my quick testing Web UI translations that use the Context of a GUI classes aren't translated when the build is configured with `--disable-gui`.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@glassez commented on GitHub (Feb 2, 2019):

Well, I had to waste my time...

@Piccirello, the problem is how you handle the category menu. Compare it to the plugin menu, which is implemented more correctly. In plugin menu you store both Display names (translated) and values (i.e. identifiers) so "All plugins" ans "Only enabled" items that can be translated always have correct identifiers ("all" and "enabled") stored in "value" attribute. I don't understand why you didn't do the same with the categories.

@glassez commented on GitHub (Feb 2, 2019): Well, I had to waste my time... @Piccirello, the problem is how you handle the category menu. Compare it to the plugin menu, which is implemented more correctly. In plugin menu you store both Display names (translated) and values (i.e. identifiers) so "All plugins" ans "Only enabled" items that can be translated always have correct identifiers ("all" and "enabled") stored in "value" attribute. I don't understand why you didn't do the same with the categories.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@glassez commented on GitHub (Feb 2, 2019):

The current practice for all Web UI translations is to reference the appropriate GUI class with the same text.

This is a legacy of the outdated approach, when translation from GUI was used in Web UI.

@glassez commented on GitHub (Feb 2, 2019): >The current practice for all Web UI translations is to reference the appropriate GUI class with the same text. This is a legacy of the outdated approach, when translation from GUI was used in Web UI.

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@Piccirello commented on GitHub (Feb 2, 2019):

When did this approach change?

@Piccirello commented on GitHub (Feb 2, 2019): When did this approach change?

deekerman commented

2026-02-21 19:33:55 -05:00

Author

Owner

@glassez commented on GitHub (Feb 2, 2019):

When did this approach change?

#9026
Now Web UI uses independent translations. But context names are still legacy.

@glassez commented on GitHub (Feb 2, 2019): >When did this approach change? #9026 Now Web UI uses independent translations. But context names are still legacy.

deekerman referenced this issue

2026-02-21 22:09:14 -05:00

Independent RSS feeds refresh timer for each folder #11955

deekerman referenced this issue

2026-02-22 00:27:15 -05:00

More granular RSS rate limiting #13890

deekerman referenced this issue

2026-02-22 00:27:33 -05:00

Handle RSS Feed Rate Limiting #13896

deekerman referenced this issue

2026-02-22 01:01:57 -05:00

Ability to stagger RSS feed refresh interval for individual rules #14404