KFC vs. Kentucky Fried Chicken

[Adamant1]

@davidoskky

Should we use local names or a globally accepted one to name things?

Generally we should use the local name. In this case though we are talking about a global brand, globalish preset in iD Editor, and Nominatim is a global search engine. So the globally accepted name is what matters here. Not what someone in North Korea calls the restaurant. Otherwise, we could create local variations for the presets in iD Editor (it already has them to some degree) but I don’t think that don’t think would ultimately fix the problem with Nominatim’s search results. If anything it would just make the problem worse. I mostly agree with the rest of what you said, but the contention here mainly comes down to how we use the name tag.

@n76

I would not spell out IBM to International Business Machines. Or 3M to Minnesota Mining and Manufacturing.

I wouldn’t either. KFC is kind of a different animal then companies like IBM or 3M though because it’s a global brand with 25,000 locations world wide. Really, they aren’t even comparable. To the point that you can’t just extrapolate how you’d tag some random 3M warehouse in your local area to how people should tag Kentucky Fried Chicken restaurants.

@alan_gr

It seems the company itself has changed approach at certain times

This is from their Wikipedia article “In 1991, the KFC name was officially adopted, although it had already been widely known by that. Kyle Craig, president of KFC U.S., admitted the change was an attempt to distance the chain from the unhealthy connotations of “fried”.” From what I remember they also wanted to get away from being mainly associated with chicken products. Either way, it mostly failed and now they use both names interchangeably or a completely different one. Even outside of the United States like with Dieterdreist’s example of what people call it in Germany and PFK in French Canada. There isn’t really a “common” name for Kentucky Fried Chicken though

[mmd]

@dieterdreist

in Germany, typically it is called Kentucky schreit ficken, although you would maybe not expect this as nat_name in a map

Right, the version @dieterdreist mentioned is inspired by some sort of spoonerism and was pretty famous as Saturday night comedy back in the nineties: https://www.youtube.com/watch?v=U-h0Jikw6WQ

And no, it’s not the official name in use, and some folks might even find it slightly obscene nowadays…

[Minh_Nguyen (Minh Nguyễn)]

@davidoskky

Should we use local names or a globally accepted one to name things?
I think this is the main argument of debate here.

name is the “primary” name, which is a simplistic way of saying that we sometimes have to weigh multiple good options using common sense. Sometimes the local name is the most verifiable on the ground, but sometimes out-of-towners are so unfamiliar with it that it has to be relegated to loc_name to avoid confusion. Other times, out-of-towners have continued to use an outdated name out of habit and apathy. This gets even more complicated when an individual store location is part of a chain. Sometimes chains let individual franchises cobrand their locations. This is especially common at roadside amenities like restaurants and gas stations.

@davidoskky

Thus the main problem is how to let everybody around the world understand which shop that is, as well as letting local people understand what that is?

There’s a longstanding practice to tag multinational brands based on local realities. After all, we’re making a map, not just a business directory. The name suggestion index supports this practice by maintaining multiple entries for the same brand that can be scoped to different geographies. Currently, NSI has 613 amenity=fast_food entries associated with 559 distinct brand:wikidata values. There are seven entries for KFC, including PFK in Québec. These redundant entries aren’t always due to translation into other languages. Many foreign brands in Japan cobrand with a local name, such as Showa Shell.

@Adamant1

In this case though we are talking about a global brand, globalish preset in iD Editor, and Nominatim is a global search engine. So the globally accepted name is what matters here. Not what someone in North Korea calls the restaurant.

By the way, most search engines support both global and proximity-based searching for different use cases. When I use Organic Maps in the U.S., I care much more about finding the restaurants near me based on the names they use in the U.S., even if the chain is usually called another name in its home country. On the other hand, when I’m abroad, it’s really nice to be able to find a familiar brand by the names I know back home. A search engine could use either NSI or Wikidata to cross-reference brands by their names specific to other places.

There have even been musings about search engines and renderers using brand:wikidata to display some familiar logos based on brand:wikidata, just as iD does today for NSI presets. To @Peter_Elderson, Colonel Sanders’ face on the map might as well be a , but no map of a Japanese city is complete without 7-Eleven’s logo all over the place. (It’s literally part of the map key on Japanese maps.)

[Mateusz_Konieczny]

@Adamant1

Generally we should use the local name. In this case though we are talking about a global brand, globalish preset in iD Editor, and Nominatim is a global search engine. So the globally accepted name is what matters here. Not what someone in North Korea calls the restaurant

This does not override anything. If KFC in Foobarstan operates under name KFD and that is how their locations are named by local people, then iD editor and Nominatim needs to deal with it somehow.

name=KFD is correct in such case, no matter how inconvenient it is for some data consumers (as mentioned, if someone wants some unified handling they can use brand:wikidata processing for that)

[Adamant1]

@Mateusz_Konieczny

This does not override anything. If KFC in Foobarstan operates under name KFD and that is how their locations are named by local people, then iD editor and Nominatim needs to deal with it somehow.

The reason that someone in North Korea calls Kentucky Fried Chicken KFD doesn’t matter is exactly because iD editor and Nominatim are already dealing with it. At least I assume they are. The issue comes up when you throw in “Kentucky Fried Chicken”, KFC", “K.F.C”, “K F C”, Etc. Etc. into the same search pot. No one is complaining about or cares that people in Germany call Kentucky Fried Chicken “Kentucky schreit ficken” though. So really the whole “local naming conventions” thing is a red hearing. Not that I think anyone is trying to intentionally distract people from the main point of the conversation by bringing them up, but they are extreme edge cases that aren’t really relevant to the core problem regardless.

At least as far as I’m concerned this conversation is about “Kentucky Fried Chicken” versus “KFC” and neither ultimately comes down to their local usage. If people in Germany want to re-name all their KFCs to “Kentucky schreit ficken” they can be my guests and do it I don’t think that would at all resolve this though.

[o_andras]

The point of this discussion may have flown past over my head but…

brand:wikidata will always be the only sure way to find something “globally”, by non-local names, so everything else should be local.

Let’s say in some hypothetical place it’s officially called “Kentucky Fried Chicken”, abbreviated as “KFC”, but for whatever reason people call it just “Kentucky” (“let’s go to Kentucky!”).

name=Kentucky
official_name=Kentucky Fried Chicken
short_name=KFC # or maybe `alt_name` (unnecessary if it's the same as `name`)
brand:wikidata=Q524757

What am I missing?

[Adamant1]

@o_andras

brand:wikidata will always be the only sure way to find something “globally”

This discussion was instigated because of the way Nominatim gives search results when people search for KFC/Kentucky Fried Chicken restaurants on the main website. People aren’t putting in brand:wikidata=Q524757 when they do that and I don’t think Nominatim factors it into the search results either. Since it gives plenty of results that don’t have Wikidata entries associated with them. So brand:wikidata will always be the only sure way to find something “globally” (which is questionable anyway) but brand:wikidata doesn’t have anything to do with this.

That said, I had suggested creating more local entries for KFC/Kentucky Fried Chicken in the Name-Suggestion-Index. As I told @Mateusz_Konieczny that doesn’t really resolve the underlining problem of people being unable to find KFC/Kentucky Fried Chicken restaurants when they search for them though. I put that on this being split off from the main topic where it was originally posted, which unfortunately led to the surrounding context of why we are having this discussion being totally lost. Like I said somewhere else though, there is no “globally common” way of tagging KFC/Kentucky Fried Chicken. Tagging them as Kentucky Fried Chicken just has the benefit of not screwing up the search results. Other people decided to ignore that and make purely about the minutia of local tagging conventions or whatever. When how locals tag things aren’t really relevant. The intent behind my original message had nothing to do with relitigating how local mappers do things though, when it comes to KFC or anything else.

@o_andras

Let’s say in some hypothetical place it’s officially called “Kentucky Fried Chicken”, abbreviated as “KFC”, but for whatever reason people call it just “Kentucky” (“let’s go to Kentucky!”).

In that case I assume it would just be filtered out of the search results and whoever is doing a search for “KFC” would get results for the other 20,000 restaurants that aren’t locally called “Kentucky” but also still happen to not be what they were looking for

[o_andras]

@Adamant1

So brand:wikidata will always be the only sure way to find something “globally” (which is questionable anyway) but brand:wikidata doesn’t have anything to do with this.

You’re reading that on a different level. Hopefully, humans won’t have to search for brand:wikidata=Q524757 to find KFCs nearby! But for a computer, that should be the best way to find KFCs nearby, if it knows some terms related to that Wikidata entry (e.g. “KFC”, “Kentucky Fried Chicken”, …).

The problem of all KFC restaurants being or not tagged with brand:wikidata is a different one. And that’s not to say that tagging all restaurants with their correct brand:wikipedia, when available, is the only way to improve the situation.

@Adamant1

That said, I had suggested creating more local entries for KFC/Kentucky Fried Chicken in the Name-Suggestion-Index. As I told @Mateusz_Konieczny that doesn’t really resolve the underlining problem of people being unable to find KFC/Kentucky Fried Chicken restaurants when they search for them though.

Right.

@Adamant1

In that case I assume it would just be filtered out of the search results and whoever is doing a search for “KFC” would get results for the other 20,000 restaurants that aren’t locally called “Kentucky” but also still happen to not be what they were looking for

It’s possible I misunderstood you, but: how?

If an hypothetical search system knows that “KFC” is a common term to mean Q524757, then restaurants tagged with brand:wikidata=Q524757 should show up in the results, whether restaurants are locally tagged with name=KFC or not (or other similar variants).

OTOH, if you search for “Kentucky” alone in that hypothetical search system, restaurants tagged with name=Kentucky should show up in the results as well, whether or not they are also tagged with brand:wikidata=Q524757.

Does that make sense? If I’m thinking clearly and managed to explain myself clearly, it should be easy to understand that this approach works globally for both locals and non-locals.

---

Anyway, the thread is under “Tagging general discussion”, but this is not a tagging problem, is it?

[Minh_Nguyen (Minh Nguyễn)]

@o_andras

Let’s say in some hypothetical place it’s officially called “Kentucky Fried Chicken”, abbreviated as “KFC”, but for whatever reason people call it just “Kentucky” (“let’s go to Kentucky!”).

Or in China.

[Adamant1]

@o_andras

If an hypothetical search system knows that “KFC” is a common term to mean Q524757, then restaurants tagged with brand:wikidata=Q524757 should show up in the results, whether restaurants are locally tagged with name=KFC or not (or other similar variants).

Sure. I don’t disagree with that, but it assumes 100% of KFC restaurants in OpenStreetMap are tagged with brand:wikidata=Q524757. Which is clearly not the case and probably never will be. So the question what the instances that don’t have brand:wikidata=Q524757 should be tagged as. Although, it’s also important what results people get in cases where brand:wikidata=Q524757 does exist, because I as an American doing a search for KFCs in Northern California shouldn’t be getting results for Kentucky Fried Chicken in Tokyo Japan. Which is what seems to be currently happening even though the results are tagged with ‘name=ケンタッキーフライドチキン’ and 'brand:wikidata=Q524757. I clearly shouldn’t be getting results for “ケンタッキーフライドチキン” when I search for KFC in Northern California whatever the particulars of brand:wikidata are though. BTW, if I do the reverse and search for ‘ケンタッキーフライドチキン’ in Tokyo, Japan it doesn’t send me to a KFC restaurant in Northern California

@o_andras

Anyway, the thread is under “Tagging general discussion”, but this is not a tagging problem, is it?

That’s because the discussion was moved here from another forum by Tordanik. Although it’s still kind of a tagging problem, or at least I think there’s a better chance of this being fixed through tagging then there is it somehow magically getting dealt with on Nominatim’s side. Sure though, you could probably solve this by either improving Nominatim, adding brand:wikidata to every restaurant, or re-tagging all the locations that don’t have a preferred local name to Kentucky Fried Chicken. Maybe the last option isn’t the “best” one, but it has the best chance of actually being doable.

[davidoskky]

@Adamant1

At least as far as I’m concerned this conversation is about “Kentucky Fried Chicken” versus “KFC” and neither ultimately comes down to their local usage.

After all points have been discussed, I guess you should file a new entry for “Kentucky Fried Chicken” in the NSI. This one should not override the “KFC” one since that is clearly used in other places around the world.

[o_andras]

@Minh_Nguyen

Or in China .

I had no idea! lol

@Adamant1

Sure. I don’t disagree with that, but it assumes 100% of KFC restaurants in OpenStreetMap are tagged with brand:wikidata=Q524757. Which is clearly not the case and probably never will be.

It’s not assuming anything, it only explains how features tagged with brand:wikidata can show up in the results. I know that it’s close to impossible for all features ever to be correctly tagged at all times, unfortunately. But that’s a different issue (as I already said) than the “correct” way to tag a particular feature.

@Adamant1

So the question what the instances that don’t have brand:wikidata=Q524757 should be tagged as.

If you agree that, ideally, KFCs should be tagged with brand:wikidata=Q524757, and also believe that it’s close to impossible to have all KFCs correctly tagged at all times (see above), then what’s the point of discussing the “correct” tags for KFCs with no brand:wikidata=Q524757? We’re back to square one: even if we agreed on a common tagging scheme for KFCs with no brand:wikidata, how would we make sure all KFCs with no brand:wikidata will follow this scheme, given that we can’t make sure all KFCs have brand:wikidata?

@Adamant1

Although, it’s also important what results people get in cases where brand:wikidata=Q524757 does exist, because I as an American doing a search for KFCs in Northern California shouldn’t be getting results for Kentucky Fried Chicken in Tokyo Japan.

That’s fair enough, but again not a tagging issue because if KFC is called “ケンタッキーフライドチキン” in Japan, it should be tagged that way.

A hypothetical search system could return more relevant results (e.g. closer to you) if it knows where you are (or where you want to search).

I don’t know particulars, but in case you mean the search feature of the main osm.org site, I believe it doesn’t know where you are and doesn’t take into account the bbox currently shown on screen either. And if the site doesn’t know where you are, IMO it makes sense to include results from all around the world.

@Adamant1

Although it’s still kind of a tagging problem, or at least I think there’s a better chance of this being fixed through tagging then there is it somehow magically getting dealt with on Nominatim’s side.

Again, I don’t know particulars so I can’t comment on which would be easier.

[SimonPoole]

@o_andras

I don’t know particulars, but in case you mean the search feature of the main osm.org site, I believe it doesn’t know where you are and doesn’t take into account the bbox currently shown on screen either.

It does. …

[Adamant1]

@o_andras

But that’s a different issue (as I already said) than the “correct” way to tag a particular feature.

Obviously. Your the one that brought it up originally. My original comment had nothing to with brand:wikidata and as I’ve said a number of times now I don’t think it’s relevant.

@o_andras

That’s fair enough, but again not a tagging issue because if KFC is called “ケンタッキーフライドチキン” in Japan, it should be tagged that way.

A hypothetical search system could return more relevant results (e.g. closer to you) if it knows where you are (or where you want to search).

Like @SimonPoole said the search system takes into account where I am when I do a search. Or at least it should. So it 100% is a tagging issue. Since all things being the same with a KFC in Japan versus one in Northern California where both have brand:wikidata=Q524757 the only reason I would be getting a result for the restaurant in Japan is because of how it’s tagged. Same goes for if I search for “Kentucky Fried Chicken” in Northern California, which gives me a result in China. Obviously I wouldn’t be getting results for those specific restaurants if they weren’t tagged with English language phrases like “Kentucky Fried Chicken” and KFC since if I search for “ケンタッキーフライドチキン” it gives me a restaurant specific to Japan even though it shares brand:wikidata=Q524757 in common with locations in the United States.

Extrapolating from that, I assume if the KFC’s in the United States were Retagged to “Kentucky Fried Chicken” that I wouldn’t at least be given the location in Japan in the search results. Since it wouldn’t share KFC in common with the locations in the United States anymore. Just like if I search for “ケンタッキーフライドチキン” I don’t get KFC restaurants in the United States because none of them are tagged as “ケンタッキーフライドチキン”. Otherwise, what else would be the problem be caused by? I don’t think it’s an issue on Nominatim’s side since like I said it doesn’t give results for the United States when I search for “ケンタッキーフライドチキン” in Japan. So I don’t know what else it could be or any other solution besides how they are tagged.

[Adamant1]

@davidoskky

After all points have been discussed, I guess you should file a new entry for “Kentucky Fried Chicken” in the NSI. This one should not override the “KFC” one since that is clearly used in other places around the world.

Yeah, I think they need their own entry for the United States with “Kentucky Fried Chicken” as the name. Although it still might cause the search give the results in China, but it would be an improvement either way. Conversely, we could just not tag KFC restaurants in non-English speaking countries with English phrases by default, but unfortunately I doubt that would ever get off the ground.

[o_andras]

@SimonPoole

It does. …

Does what, specifically? Use the user’s current position or take into account the bbox on screen?

I don’t remember seeing osm.org ask for my position, ever. In fact, I just checked for the permissions on my browser and it’s never asked for any permission. So I guess it takes into account the bbox? At most…

@Adamant1

You’re the one that brought it up originally.

I wasn’t.

@Adamant1

I don’t think it’s relevant.

You keep bringing up the “correct” tagging scheme for KFCs as the problem, and yet you say brand:wikidata is irrelevant? It certainly is relevant, unless we’re speaking about different problems.

And why are you so (seemingly) fixated on tagging for Nominatim? As far as I can see, this is not a tagging problem (yes, again…).

And yes, again: how are you gonna enforce your new set of tags to improve search results if you can’t enforce correct use of brand:wikidata? Sounds like a fool’s errand to me.

@Adamant1

Like @SimonPoole said the search system takes into account where I am when I do a search. Or at least it should.

@SimonPoole wasn’t clear about that, see above.

And “should” is a matter of opinion. I don’t need or want osm.org to know where I currently am so, to me, it should not. Using the bbox to show more relevant results would be a nicety but… Meh, not useful enough to be worth the effort IMO. When I really want to find something I can turn to Overpass/OsmAnd/Organic Maps.

@Adamant1

So it 100% is a tagging issue.

If your only problem is the search results, and you already know that it’s solvable by making the results local (i.e. near you), why do you still insist this is a tagging issue? Can you share examples of KFCs tagged incorrectly?

@Adamant1

Obviously I wouldn’t be getting results for those specific restaurants if they weren’t tagged with English language phrases like “Kentucky Fried Chicken” and KFC since if I search for “ケンタッキーフライドチキン” it gives me a restaurant specific to Japan even though it shares brand:wikidata=Q524757 in common with locations in the United States.

I can think of a few reasons why what you seem to be implying is wrong.

1. For starters, if anywhere in the world KFCs are called “Kentucky Fried Chicken”, then they should be tagged that way.

2. I was here and searched for “Kentucky Fried Chicken”. The first result was this, the second was this, and the other 8 results were all in the US (like the second). By what you seem to me to be proposing, instead of “blaming” the search system, I should go around the world and change all of the KFCs outside of Portugal (where I live) so that the search results will all be local to Portugal. I hope I’m misunderstanding you, but that’s plain stupid.

3. You seem to be proposing we should change KFCs in Japan to not include “KFC” or “Kentucky Fried Chicken” in their tags, even if they’re correct. In Japan you’re (almost) lucky because they have the tradition of transliterating most non-Japanese to Japanese (they still use “KFC”). However, in Portugal there’s no such tradition: “Kentucky Fried Chicken” is called “Kentucky Fried Chicken”, not “Frango Frito Kentucky”; “Burger King” is called “Burger King”, not “Rei dos Hamburgers”; “Domino’s” is called “Domino’s”, not “Do Dominó”; “Honest Greens” is called “Honest Greens”, not “Verdes Honestos”; “The Good Burger” is called “The Good Burger”, not “O Bom Hamburger”; … (silly translations on purpose) How do you untie this knot?

4. Finally: if a Japanese person searches for “ケンタッキー フライド チキン” in the US, should they be shown results in the US or not? Or vice versa: if you search for “Kentucky Fried Chicken” in Japan should you be shown results in Japan or not? I say yes to both. Ideally, I should be able to search however I’m comfortable searching and get relevant results even if I’m abroad! What you seem to be suggesting, however, is that neither you nor the Japanese person should get any results.

---

In short: are you suggesting that the use of English names outside of the US are wrong?

What the heck is the real problem that we’re supposedly discussing here? It’s probably in part my fault, but I feel like we’re going in circles for no reason…

[Adamant1]

@o_andras

I wasn’t.

Your right. Minh brought it up, you responded to him, and then I responded to your comment. My bad. That said, your the one who keeps bringing it up as a talking point. It wasn’t and isn’t something I think matters to this regardless of who first brought it up though.

@o_andras

You keep bringing up the “correct” tagging scheme for KFCs as the problem, and yet you say brand:wikidata is irrelevant? It certainly is relevant, unless we’re speaking about different problems.

It’s possible we are talking about different problems. My problem is that if you have two Kentucky Fried Chicken restaurants, with one being in Japan and one being in the United States and where both have brand:wikidata=Q524757 the search results will give you the restaurant in Japan. Even if the bbox is in Northern California when you do the search. So how exactly is brand:wikidata=Q524757 at all relevant there? Both restaurants have the tag. I assume Nominatim assigns both the same weight. So it literally has zero effect on the search results.

@o_andras

And why are you so (seemingly) fixated on tagging for Nominatim? As far as I can see, this is not a tagging problem

I’m not fixed on anything. Like I said before, this was originally a discussion about Nominatim’s inconstant search results when people want to find KFC restaurants until Tordanik moved it from the original discussion. This discussion wouldn’t have been started or matter at all if it wasn’t for that though and it’s always been about Nominatim on my end. I didn’t create the title of this discussion or put it in this category and I’ve never claimed it was a general discussion about tagging. No where have I said we should “tag for Nominatim” either. Personally, I just want to be able to find a KFC restaurant in the United when I search for one, which I think would be accomplished by changing the tagging. That doesn’t mean I’m “fixed on tagging,” I could ultimately care less what solution results in me being able to find KFCs in the United United States, but no one including you has posed another solution beside re-tagging them.

@o_andras

You keep bringing up the “correct” tagging scheme for KFC

No I don’t. I’ve said multiple times that there is no “common” or “correct” way to tag KFCs in the United States because they are known as both KFC and Kentucky Fried Chicken about as equally here.

@o_andras

how are you gonna enforce your new set of tags to improve search results

I’m merely suggesting a solution to the inconsistent search results in a discussion forum. In no way is that “enforcing my set of tags” on anything or anyone.

@o_andras

@SimonPoole wasn’t clear about that, see above.

Not to speak for SimonPole, but you asked if the search takes the bbox into account and he said it did. That sounds pretty clear to me. As far as I know it does. There’s a couple of comments on Nominatim’s Github page like here where [kshmidman says “we restrict results with bbox.” There’s also this issue that relates to Using OSM location to increase importance. So I assume that’s something it also does. Maybe both are failing in this case though. But the fact that it only occurs when I search for KFC in the United States makes me think that’s not what’s going on.

@o_andras

For starters, if anywhere in the world KFCs are called “Kentucky Fried Chicken”, then they should be tagged that way.

No really? Where have I ever said otherwise. What part of “there is no common name for Kentucky Fried Chicken in the United States” translates into “Kentucky Fried Chicken shouldn’t be called “ケンタッキーフライドチキン” in Japan” to you?

@o_andras

You seem to be proposing we should change KFCs in Japan to not include “KFC” or “Kentucky Fried Chicken”

That’s not what I’m proposing.

@o_andras

if a Japanese person searches for “ケンタッキー フライド チキン” in the US, should they be shown results in the US or not?

I don’t really care should be or not. I was merely using it as an example of where if you search for KFC in a specific country like Japan the results are for that country. Whereas, if you do a search for KFC in the United States they aren’t. That’s it.

quote=“o_andras, post:36, topic:4769”]
instead of “blaming” the search system
[/quote]

Yeah OK. Me saying the search results don’t work in the United States and trying to find a solution for that is “blaming the search system.” Sure, whatever you say dude. Do you have anything actually constructive to add to this discussion are you are just here to insult me and repeatedly mischaracterize my position?

[markkerrigan]

I’ve read this whole topic and it seems like the issue is mainly about Nominatum.

So I did do a search for KFC and received results for in Japan. But one can also add the city into the search and get location contextually useful results.

For example, “KFC Seattle” and “Kentucky Fried Chicken Seattle” is returning the same result (which is a combination KFC and Taco Bell).

For what it’s worth I also did a search on OrganicMaps which gave me location contextually results for both “KFC” and “Kentucky fried chicken”. OSMAnd also gave contextually useful results but “Kentucky Fried Chicken” returned different results than “KFC”.

I don’t see an issue with the tagging, the problem seems that Nominatum does not return the expected results. But other applications are able to handle this case so the results are useful

[lonvia]

When searching on osm.org, then there is a preference for places in the map view that is currently visible. The preference is for what you are looking at, not for where you physically are. Nominatim never gets any information about your current location. The catch here is that the preference is rather weak. Nominatim will prefer full matches in name tags over the viewbox any time. It also doesn’t know about “KFC” == “Kentucky Fried Chicken” unless it is tagged this way.

In the long run, I think that brand:wikidata is indeed the way to go to make sure you can type ‘KFC’ and find the location in Tokyo without having to add translations for all languages. So my recommendation would be: set ‘name’ to whatever is the locally most used variant and add ‘brand:wikidata’.

If you are interested in seeing support for brand:wikidata in Nominatim rather sooner than later: this is a topic somebody with reasonable programming experience (preferably in Python) can help out with. Please open an issue in Github to ask for technical details.

[o_andras]

@Adamant1

you asked if the search takes the bbox into account

I asked if the search takes into account the bbox OR the user’s position. By replying yes, they could mean either or both.

@Adamant1

@o_andras

instead of “blaming” the search system

Yeah OK. Me saying the search results don’t work in the United States and trying to find a solution for that is “blaming the search system.” Sure, whatever you say dude. Do you have anything actually constructive to add to this discussion are you are just here to insult me and repeatedly mischaracterize my position?

It seems you don’t much like reading what others write, in which case I don’t see a point in replying to you anymore. If you’d like, you could re-read what I wrote carefully and then reply again, instead of taking a bit of what I wrote out of context and “replying” to that so offended.

Also note that I tried pretty hard not to put words into your (figurative) mouth – e.g. by writing “you seem to be proposing this” rather than “you’re proposing this”. When I happened to write something like “you’re proposing this” take it to mean “you seem”, because that’s the best I can possibly know.