GNOME Bugzilla – Bug 657745
Search for applications in both English and local language.
Last modified: 2018-05-24 13:19:50 UTC
When overview mode, typing starts searching for applications in the localized language. It should be also searching in English. This is why: 1) If user has to switch between several differently localized computers, this could help use all of them efficiently. 2) Not all applications are localized. For example, if eog was not localized in Latvian, typing "Attēlu skatītājs" will not return any results, so I would want to search by "Image viewer", which won't work if it's localized. Usually the program name already has some keywords in it, but not always.
I strongly agree with point 1. I have encountered the issue of not being able to find something a couple of times because of different languages used. A lot of people are at least bilingual these days. English and another language is probably the most common case. I agree that since we already treat English as the lowest-level fall-back language, it should be enabled by default when searching for applications in the dash. Enabling English will also help in making Gnome a lot more friendly for people who set their language to Japanese; it is quite bothersome to have to use the IME for a quick search in the dash. Not to mention that the dash is broken at the moment for Japanese input: Bug 647707.
Few more points: in 3.6 you can't switch keyboard layout when the overview is open (known bug, I think), so this is another reason to support this. Furthermore, I'd argue the shell should search in any language available in the desktop files, even if you are on English locale and typing in Hebrew, for example.
As far as I can tell, the current implementation already allows searching both the translated app name or the name that is part of its commandline, so I'm suspecting this should be fairly easy for a newbie to tackle. You'd probably just have to modify the code that looks at the .desktop files to include both the localized name and the original, untranslated name field in the searchable words.
(In reply to comment #3) > You'd probably just have to modify the code that looks at the .desktop files to > include both the localized name and the original, untranslated name field It is worth noting that we don't parse any .desktop files in the shell itself, but use the appropriate APIs from GMenu / Gio. In other words, you'll need to extend GDesktopAppInfo first.
Is this bug report still valid? I am on Fedora 20 with GNOME 3.10.2, and I can search for applications both with their English and localized Turkish names. For example, both "Contacts" and "Kişiler" bring the same app on GNOME Shell.
Yes, this is still relevant. I assume for contacts it works because the executable is named gnome-contacts. But in many cases the English name is not part of the executable name.
As Elad says, this is not fixed. For example, the GUI title of "seahorse" is "Passwords and Keys" in English and "ססמאות ומפתחות" in Hebrew. One frequently overlooked practical side to it is that solutions for people's technical problems can be easily googled up in English, but frequently not in other languages. The replies to technical questions in forums, knowledge bases and so on, use the English names of the apps. "Passwords and Keys" cannot be found if I use GNOME in Hebrew, and I'd really prefer not to switch the language just to fix one problem. It can be found using "seahorse", but this is an internal technical name.
(In reply to Florian Müllner from comment #4) > > It is worth noting that we don't parse any .desktop files in the shell > itself, but use the appropriate APIs from GMenu / Gio. In other words, > you'll need to extend GDesktopAppInfo first. So we should wait until the relevant API appeared in GMeno / Gio? If so, is it appeared now?
(In reply to Isaac Ge from comment #8) > So we should wait until the relevant API appeared in GMeno / Gio? > > If so, is it appeared now? No, but we stopped using GMenu altogether and application search itself is now implemented in GIO, so moving the bug there.
It would be relatively easy to pull some additional (untranslated) keys out of the desktop file. What is uncertain is: 1) do we want to? 2) if so, at what priority do we consider the additional results? If we did this, then presumably English-language matches would rank below the ones from the current locale...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/443.