76
7 days later

I agree with this question and answer it. In the case of German and English, since the same alphabet is used, there may be ambiguity when judging the user's intention, but in the case of Korean users, they will not expect a Korean site to come out as a result of the search while searching in English.
Fortunately, if the region is set as "international", it seems to operate similarly to what is desired.

I don't use Roman alphabets such as Japanese, Chinese, and Vietnamese, and I think users from other countries where the language is mainly concentrated in one country will expect a similar experience as me. Although it is controversial depending on the user's country what initial regional setting is good, since Kagi is a membership search engine, wouldn't it be an alternative to explicitly ask about the user's expectations during the sign up process?

    a month later

    I would also love to see the option to set (allowed) search result languages independent of the region. For example, I moved from Germany to Estonia and would love to continue to get localized results for certain queries. Unfortunately, I don't speak Estonian, so most of the localized results are not super useful to me.

    Google allows you to define a list of languages that you would like your results to appear in. In my case, that would be English and German (preferably in that order), and it would need to be independent of my region. I would therefore love to see something similar to this being available on Kagi as well. The cherry on top would be to immediately translate those results if desired, but I understand that this may be a bit too special.

    8 days later

    One possible solution would be to select the language based on the one in the user browser, while keeping the user region.
    In my case, I tend to use kagi in french for personal stuff (browser set in french), but I use it in english for work stuff (browser set in english).
    All that while keeping the region the user selected.

    • Vlad replied to this.

      Vlad

      • the ability to select a language for search independently from the region
      • the ability to select a different language depending on the device, with the default being the OS/browser language
        All this is difficult today in the perspective of having paid account. Otherwise, having two separate accounts would solve the issue

          EmmanuelKrebs Can you please details with use cases

          • what kagi does wrong today
          • describe in detail/through same examples how would you change it

          Your proposed changes are not minimal at all so I want to make sure I full understand them.

              a month later

              I have the same issue: I am fluent in both English and German, and located in Germany. When I search for a product, object, or person, kagi displays results mostly in German, which I dislike, since it restricts me to the German-speaking part of the web, which is small (German-speaking forums, news outlets etc). On the other hand, if I set kagi to be international, I get no preference for local businesses and news at all, which is also not ideal (since there's a big correlation between language and location, and thus relevance). In the end, I would just like all languages that I speak to be included among search results. The UI that I imagine is simple: just a long list of checkboxes, one for each language. With those checkboxes auto-checked initially that are inferred e.g. from by browser settings and region, but respecting and remembering any choices that I make. Equal weight should be given to all selected languages. I'm only now noticing how the search engine that must not be named seems to get this balance right.

                cupe We would appreciate if you could share examples from other search engines - few example searches and comparison of kagi results vs the other engine

                    15 days later

                    Vlad Thinking about it, the problem may be that Kagi is too strict about the language being filtered. If I set my location to Estonia, I would get local results for queries like tallinn spa. But if i then search (for example) for wiki apple, I would also get a lot of results in Estonian for that query. Since I don't understand Estonian, I change it back to International. Now, if I search for tallinn spa I won't get any results in Estonian and therefore miss out on good results, as most of the pages aren't available or indexed in English.

                    Google on the other hand isn't so strict about the language setting. It will show Estonian results if it thinks the query is still relevant, due to the location indicated in the query. A workaround would be to have the option to define a (prioritized list) of languages that the user understands.

                    • Vlad replied to this.

                        KarimG We are strict on purpose. if the user shows intent we do our best to follow it through. Finding balance is tricky.

                            Vlad here's a good example: I'm searching for "gochugaru" (a Korean cooking ingredient). Kagi, when set to German, shows me some options to buy the stuff locally (good) and the very few German-language articles on it that are all not very good, e.g. there's no article in the German-language Wikipedia about it (bad). Switching kagi to "International" shows me some better-quality articles including the one in the English Wikipedia (good) as well as some options to buy it in the US which are useless to me, and no option to order it from Germany (bad).
                            Searching for the same search term with google, which I set to allow both English and German results, shows both the good articles and the option to buy that I can actually use (Wikipedia article and amazon.de are the top two results), so I get all the good parts in one.
                            On kagi, to get both the good content about it and the websites where I can source the ingredient, I have to toggle kagi's language setting back and forth and repeat the search, which is of course too annoying to actually do.

                                cupe That's a valid criticism from a user perspective.

                                    2 months later

                                    To add to what @cupe said, identifying country with language is by itself problematic, because that mapping is not one to one.

                                    E.g. I am a speaker of a minoritised language (Catalan) spoken in two different internationally recognised countries (Spain and France). My browser search preferences are set to catalan, with English as a second option and Italian as a third. I don't habitually speak Castilian (the language typically known internationally as "spanish"), so I prefer not to get results in that language if alternatives are available in my languages of choice.

                                    My search options in Kagi are set to international because I have no option to select "Catalan". However, when I perform a local style search like "Caixaforum Barcelona" the results come out it Spanish (for no identifiable reason, given my preferences). The same search performed in Google (that lets me select my preferred language) produces results in Catalan. This alone is a reason for me to not use Kagi for searches where I want to prioritise results in my language (in my case, anything local really).

                                      txels Thanks for describing this use case.

                                          9 months later
                                          18 days later

                                          Language and region can be orthogonal and 2-dimensional. The upsides are well enumerated already.

                                          The downside is an exponential increase in complexity since let's say the medium term plan is to support 10 languages and 20 regions, that's 20x10 or 200 possible combinations. And that would still be very far from the Catalan case, which would probably require thousands or tens of thousands of language-region pairs to service (if implemented based on descending popularity of the pair).

                                          Maybe a trial implementation could be done with just 3 languages and 3 regions? And then evaluate the real world pros/cons a year later?

                                          4 months later

                                          Hello.

                                          I found a few other discussions concerning language support, but to avoid mixing, I thought it was better to create a new thread.

                                          I am in switzerland, I work in english as a programmer and my wife is japanese, so let's say I change language often.

                                          I did some thinking, and there are three parameters I'd like to be able to manipulate:

                                          • query language
                                          • response language
                                          • region

                                          The query language is important because it cannot be detected reliably in a lot of situation. For example a lot of french words are the same as in english, or some japanese kanji are the same as chinese/taiwanese.

                                          The response language is also of course important, and it should be a different setting that the query language. In many situation it will be the same, but sometimes not, for example if I search for french lessons in japanese, I query in french for japanese results.

                                          Finally the region. This settings already exists, but I am just mentioning it for completeness.

                                          Also, the browser language is irrelevant for query and results, and is only important to detect UI language default.

                                          I would love the following features:

                                          • syntax to specify query/response language in a query, like: l:fr for response language, ql:fr for query language and r:ch for region.
                                          • the ability to add language lenses separately from existing lenses, a language lense would include the three settings as list, for example: query language: raise fr, en, block de. response languge: only fr, region: world