description related to tag starting with name is removed

[draunger]

Description:

approach

i have used slice method which slice the key which are starting with name and checks the condition after slicing

attached screenshot after the fix

before this fix

attached issue

#10287

[Dimitar5555]

I've just did a quick test and it seems like you can add name: true to this list and it will catch all name:xx variants, without all of the extra code you added. It is likely using some sort of regex under the hood, but I haven't looked for it.

iD/modules/services/taginfo.js

Lines 196 to 209 in 49492a0

	_popularKeys = {
	// manually exclude some keys – #5377, #7485
	postal_code: true,
	full_name: true,
	loc_name: true,
	reg_name: true,
	short_name: true,
	sorting_name: true,
	artist_name: true,
	nat_name: true,
	long_name: true,
	via: true,
	'bridge:name': true
	};

[draunger]

@Dimitar5555 i did this before but it does not working

[draunger]

@1ec5 please review my PR so that i can make changes

[1ec5]

Thanks for your patience. In addition to the following comments, please consider writing a unit test for the change. You can find tests related to this file at test/spec/services/taginfo.js.

[1ec5]

I was wondering how this service excludes name, since it isn’t explicitly listed in _popularKeys. It turns out that name happens to be one of the 100 most popular keys that we add to the _popularKeys here. (There’s some additional explanation at #7485 (comment) that I had forgotten.)

[1ec5]

String.prototype.startsWith is less error-prone than comparing a substring manually. A more thorough fix would catch any key if it’s just a localized version of any of the popular keys. A localized key looks like baseKey:xy, where xy is a language code (not necessarily two characters long). I think what you’ve got is OK, but I’d recommend switching to startsWith and also requiring a colon, like name:, in case someone types in a key that doesn’t have it like name_disaster or name_base.

[draunger]

@1ec5 as you said that start with name: will cause to name that starting without colon shows suggestion, so do i change with this key.slice(0,4)==='name' to this => key.slice(0,5)==='name:' ??

[draunger]

String.prototype.startsWith is less error-prone than comparing a substring manually. A more thorough fix would catch any key if it’s just a localized version of any of the popular keys. A localized key looks like baseKey:xy, where xy is a language code (not necessarily two characters long). I think what you’ve got is OK, but I’d recommend switching to startsWith and also requiring a colon, like name:, in case someone types in a key that doesn’t have it like name_disaster or name_base.

Now sir what I do :
1.can i just make the testcase for it and send PR for it and remaining thing should be the same??

[tyrasd]

In addition to what @1ec5 already suggested, I think it would be preferred if this would not be a hardcoded case inside an if statement deep inside the code, especially given that there is already a list of tags for this. For example, one might want to also add loc_name:xx, or description:xx to this. One possible solution would be to change _popularKeys from a dictionary to a (list of) regular expressions:

_popularKeys = [
    /^postal_code$/,
    …
    /^name:../
];

…

if (key && _popularKeys.some(regex => regex.test(key)) {
    …

As this should not be a performance bottleneck, the lost efficiency compared to the dictionary lookup should be negligible. What do you think?