Now multiCombo Languages will show human readable languages instead of ISO codes

[Razen04]

Fixes #11652

Changes made:

• displayValue function now looks at the field.key and if it is language:, it will use localizer.languageName on tval.
• renderValue function will also look at the field.key and it does the same like displayName
• The comboData array will now have value=v so that choosing 'Hindi' will not make tag as language:Hindi=yes and instead it will be language:hi=yes.

Before can be seen on the issue, here is the after image:

Btw I have a doubt, when we click on the dropdown we see some language only like Hindi is not present but when I type hi, I can see Hindi as an option and can set it, is it intentional?

[1ec5]

This is a good start, thank you!

[1ec5]

Nit: stray semicolon.

[1ec5]

Due to this change, you can search for the language code “hi” and get Hindi, but you can’t search for “hindi” and get Hindi. This also affects other combo and multicombo boxes. Some users will know the raw code but others (especially non-English speakers) will only know the localized display name. We want the user to be able to search for either. I’m pretty sure the underlying control’s implementation already knows how to search by the key, so value should be label.

[Razen04]

Sure I will work on the changes and let you know if I face any problem in between. These are the things I have understand I need to work on:

Things to do:

• Ignore the language:others basically ignore the tval=others and not let it pass through the languageName().
• Display all the languages we know about instead of getting the info via taginfo and also sort it alphabetically on the basis of it's display value.
• Fix searching.
• Fix monospace chip styling.

Do let me know if there is something I missed.

[Razen04]

I was able to do these changes, do let me know if there is something wrong.

[1ec5]

We should allow id-tagging-schema to provide its own localized string for the title of this option. Can we make the initialization of this option more consistent with the generic initialization down below?

[Razen04]

Basically we need others to get localized in different languages, I think this can be done if we use stringsField to fill the 'others' option and push in the options array.

[1ec5]

This is fine for now, but we’ll probably want to find a more data-driven approach in the future, when we enhance similar fields like Payment Methods, Currency, and Country (#7123).

[Razen04]

Yes, we will have to come up with something like specialKey boolean for payment, currency, language, and country or any others, that will be a better long-term solution for these type of keys.

[1ec5]

String.prototype.localeCompare uses the browser’s language preference, but there are a few other ways for the user to customize iD’s interface language, such as setting ?locale= in the URL. Pass in the locale code to ensure consistency. (Given the number of items to sort, best to store the locale outside of the sort() call.)

iD/modules/ui/sections/preset_fields.js

Lines 88 to 90 in aaaa972

	additionalFields.sort(function(field1, field2) {
	return field1.title().localeCompare(field2.title(), localizer.localeCode());
	});

[Razen04]

Ok I will maintain consistency and apply the changes accordingly.

[Razen04]

I have made the changes, do let me know if somethings wrong.

[1ec5]

There’s one more styling issue. Once that’s fixed, it’ll be good enough to land.

[1ec5]

Looks great, thank you for persisting through multiple iterations! In case you’re interested, #7123 would be a good opportunity for you to expand upon what you’ve built here. I haven’t opened an issue about the Currency field yet, but it’s the same idea there.

[Razen04]

@1ec5 Great! I will look into the issue you mentioned, btw can you also look at some other PR's I have made if possible like: #11667 , #11691 if you get time. Thanks for the guidance.