Feature labels are based on generic name:zh tag when using Traditional or Simplified Chinese locale

[SteveLz]

Description

Currently, neither name:zh-Hant nor name:zh-Hans are supported to be displayed on the map, but only the ambiguous name:zh, which is either traditional or simplified, is displayed.

Screenshots

No response

[1ec5]

The labeling code prefers whatever the localizer module considers to be the current language code, which is for the localization that iD’s UI is being displayed in:

iD/modules/util/util.js

Lines 183 to 184 in 25d98b1

	var localizedNameKey = 'name:' + localizer.languageCode().toLowerCase();
	var name = entity.tags[localizedNameKey] || entity.tags.name || '';

The code to choose a UI localization is a bit convoluted:

iD/modules/core/localizer.js

Lines 111 to 131 in 25d98b1

	let requestedLocales = (_preferredLocaleCodes || [])
	.concat(utilDetect().browserLocales) // List of locales preferred by the browser in priority order.
	.concat(['en']); // fallback to English since it's the only guaranteed complete language
	_localeCodes = localesToUseFrom(requestedLocales);
	_localeCode = _localeCodes[0]; // Run iD in the highest-priority locale; the rest are fallbacks
	let loadStringsPromises = [];
	indexes.forEach((index, i) => {
	// Will always return the index for `en` if nothing else
	const fullCoverageIndex = _localeCodes.findIndex(function(locale) {
	return index[locale] && index[locale].pct === 1;
	});
	// We only need to load locales up until we find one with full coverage
	_localeCodes.slice(0, fullCoverageIndex + 1).forEach(function(code) {
	let scopeId = Object.keys(localeDirs)[i];
	let directory = Object.values(localeDirs)[i];
	if (index[code]) loadStringsPromises.push(localizer.loadLocale(code, scopeId, directory));
	});
	});

But one thing we seem to have overlooked is that modern browsers generally report locale codes such as zh-Hans-CN and zh-Hant-TW based on CLDR, whereas this repository and the corresponding Transifex project only maintain zh, zh-CN, zh-HK, and zh-TW localizations. If your language preference is any of these four codes verbatim, iD will load the correct localization, but if it differs in any way, such as zh-Hant-TW or zh-Hant, then it’ll fall back to just zh.

Compounding the matter, the labeling code above only chooses the name:* subkey that matches the language part of the locale code. So when iD uses the zh-TW localization, for example, it only labels features based on name:zh, because it’s calling localizer.languageCode() rather than localizer.localeCode(). Even if it were to match the whole locale code, zh-TW is quite rare compared to zh-Hant.

We could add some special cases to both these areas of the codebase, though more robust language code matching would help not only Chinese but also other languages that frequently use more complex locale codes in the database, such as Serbian and Portuguese.

/ref #8739