KFC vs. Kentucky Fried Chicken

mmd · 2022-10-29T19:31:52.825Z

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 · 2022-10-29T19:54:58.370Z

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 · 2022-10-29T19:55:08.883Z

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 · 2022-10-29T20:12:26.999Z

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 · 2022-10-30T12:28:10.236Z

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 · 2022-10-30T19:54:24.175Z

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 · 2022-10-30T22:28:01.619Z

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 · 2022-10-31T00:25:24.016Z

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 · 2022-10-31T07:21:53.230Z

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 · 2022-10-31T08:44:32.515Z

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 · 2022-10-31T10:54:13.970Z

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 · 2022-10-31T14:50:27.012Z

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 · 2022-10-31T20:02:56.317Z

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 · 2022-10-31T20:17:11.186Z

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 · 2022-10-31T22:46:54.423Z

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.

For starters, if anywhere in the world KFCs are called “Kentucky Fried Chicken”, then they should be tagged that way.
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.
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?
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 · 2022-10-31T23:32:56.743Z

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 · 2022-11-01T07:38:00.723Z

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 · 2022-11-01T08:47:31.137Z

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 · 2022-11-02T09:43:47.206Z

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.

Adamant1 · 2022-11-02T22:01:21.645Z

o_andras:

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.

OK. I spent plenty of time reading what you wrote and I wasn’t offended by what you said. Your just wrong about what I was suggesting, why I suggesting it, and your framing of position was insulting. Something can still be insulting if the other side is offended by the insult or not though. And to me you saying I was “blaming” Nominatim and trying to “enforce” my new set of tags on people, wasn’t constructive and came off as insulting.

Am I “so offended” by what you said though? No. Your kind of behavior is pretty par for the course when it comes to discussions on here. From my end though, I just like discussions to stay on topic, not be personal, and ultimately lead to a resolution. None of that happens if someone repeatedly gets the other person’s position wrong and needlessly frames what their saying in a negative way. That’s it. Maybe you’d call that being defensive, I just call it having an objective goal for the discussion and doing what we can to reach it by not miss-constructing the other sides

o_andras:

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.

I mean, yeah, sure you said I “seemed to be proposing" retagging all the instances of ッキーフライドチキン” in Japan to Kentucky Fried Chicken, but so what? You were still wrong Like would it be cool if I were to say “you seem to be intentionally misconstruing my position in order to derail the discussion” since I said “seems” and it’s the best way know how to describe what your doing? Hey, I’m not saying you were intentionally misrepresented what I was saying as a derailing tactic, I’m just saying it “seems” like that’s what you were doing