GNOME Bugzilla – Bug 767237
Use both original and translated keywords for search
Last modified: 2018-05-24 18:55:26 UTC
Some users tend to think they have to use English for their searches in the overview, even though translators provide translated keywords. Therefore both the original and the translated keywords should work. Some translators just copy English keywords in the translation, but it's a bad workaround. As the name implies, a translation should only have translated keywords.
Application search is implemented in GIO (and Settings search, which uses keywords as well, in gnome-control-center) ...
A friend of mine has raised the issue that for some languages, a chain of fallback locales might be more appropriate. e.g. Lingala speakers would be more likely to search for French keywords than for English keywords.
I am that friend :) As she said, rather than just having English as an additional keyword language, we should pull the keywords for the official state language(s) too. Should be relatively easy to compile a list and there probably already is one. So for example, Breton (br) should also use French keywords, Basque (as it crosses nation state boundaries), French and Spanish. Of course only makes sense for locales for which there is a good translation coverage but there are actually relatively few official state languages, at a guess I'd say French, Spanish, Portuguese, Arabic, Russian, Mandarin Chinese and German probably account for a large chunk of what we're looking at at those have good coverage.
This quickly gets much too complicated
Setting a list of languages is way different from what I initially asked for. I'm merely asking to use the translation AND the untranslated string.
You may be familiar with the expression "a stitch in time saves nine"? If we are going to tackle this issue (and I believe it is quite critical) then why not fix it once in a way that means we don't have to come back to it? Once users realise they can now use English and French keywords, how long before someone files a bug to allow Catalan + Spanish without having to resort to English? For a LOT of the world, English is not necessarily the default fallback language.
First of all, the complexity of implementing both is not the same, so it makes sense to implement one before the other. Your request is a different case than mine. People use English all over the world because it's the lingua franca in the tech world. What's more, English is the language used when translation is incomplete anyway, so that would at least make it consistent by having English work for all cases. Now if you really want to have your request implemented, please file another bug.
>First of all, the complexity of implementing both is not the same, so it makes >sense to implement one before the other. Only if doing them in sequence does not mean you have to completely re-design the first solution in order for the second to work. >People use English all over the world because it's the lingua franca in the tech >world. You're thinking developers rather than end users. Yes, most of dev work happens in English and yes, a lot of technology is linked to English. But please let's step back for a moment an consider current and potential future users who are not English speakers and for whom reliance on English constitutes a real obstacle in using technology. Not everywhere is Germany or the Netherlands or France where it's French/German first, then English at a high level. There are places where you have (for example) Tibetan first, then Chinese and only then English. >What's more, English is the language used when translation is incomplete >anyway, so that would at least make it consistent by having English work for all >cases. Defaulting to English as a fallback is a serious handicap, not something to extol and emulate.
Somehow my reply got eaten up - we chold have a hieararchy of fallbacks with English at the bottom. So, implement the English fallback first, then implement the non-English solution on top of that. The CLDR data has some useful language - territory lists. http://www.unicode.org/cldr/charts/29/supplemental/index.html
*** Bug 774055 has been marked as a duplicate of this bug. ***
-- 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/1171.