Page MenuHomePhabricator

WikibaseLexeme shows language codes without language names in spelling variant dropdown
Open, Needs TriagePublic

Description

Steps to reproduce:

Actual result:

image.png (1,918×926 px, 225 KB)

  • ⧼wikibase-lexeme-language-name-bat-smg⧽ (bat-smg)
  • ⧼wikibase-lexeme-language-name-be-x-old⧽ (be-x-old)
  • ⧼wikibase-lexeme-language-name-de-formal⧽ (de-formal)
  • ⧼wikibase-lexeme-language-name-es-formal⧽ (es-formal)
  • ⧼wikibase-lexeme-language-name-fiu-vro⧽ (fiu-vro)
  • ⧼wikibase-lexeme-language-name-hu-formal⧽ (hu-formal)
  • ⧼wikibase-lexeme-language-name-nl-informal⧽ (nl-informal)
  • ⧼wikibase-lexeme-language-name-roa-rup⧽ (roa-rup)
  • ⧼wikibase-lexeme-language-name-simple⧽ (simple)
  • ⧼wikibase-lexeme-language-name-zh-classical⧽ (zh-classical)
  • ⧼wikibase-lexeme-language-name-zh-min-nan⧽ (zh-min-nan)
  • ⧼wikibase-lexeme-language-name-zh-yue⧽ (zh-yue)

Event Timeline

Well, there’s a pretty simple fix that seems to work as far as I can tell:

diff --git a/WikibaseLexeme.mediawiki-services.php b/WikibaseLexeme.mediawiki-services.php
index 9301a0c024..bd477fb09f 100644
--- a/WikibaseLexeme.mediawiki-services.php
+++ b/WikibaseLexeme.mediawiki-services.php
@@ -78,7 +78,7 @@
 		'zh-yue',
 	];
 
-	$additionalLocalizedLanguages = array_merge( $additionalTermLanguages, [
+	$additionalLocalizedLanguages = [
 		// Languages that are supported in Wikibase (via cldr) but localized here in LexemeLanguageNameLookup.
 		// These should be localized via the cldr extension (T352922).
 		'apc',
@@ -128,7 +128,7 @@
 		'tlh-piqd',
 		'txg',
 		'xbm',
-	] );
+	];
 
 	return [
 		'WikibaseLexemeTermLanguages' => static function (

$additionalLocalizedLanguages is only passed into LexemeLanguageNameLookupFactory, but that lookup shouldn’t be used for the $additionalTermLanguages. But as far as I can tell, none of the related code has been touched recently, so I’d like to first know whether this is a new issue or not (and if it is new, why it didn’t happen before).

But as far as I can tell, none of the related code has been touched recently, so I’d like to first know whether this is a new issue or not (and if it is new, why it didn’t happen before).

It's not new, I've been aware of it for a while. I think it started after the changes to use more of the language codes from the CLDR extension. It definitely worked before Special:NewLexeme was rewritten, as can be seen in the screenshot on T304494.

I probably didn't create a separate ticket for it because none of those language codes should even be in that list - T320887.

Change #1105700 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseLexeme@master] Remove $additionalLocalizedLanguages / wikibase-lexeme-language-name-*

https://gerrit.wikimedia.org/r/1105700

Remove $additionalLocalizedLanguages does not fix the issue; $additionalTermLanguages should be removed too.

This is not the same task as T320889. This task is specifically about the display of internal message keys.

But instead of displaying English language names of such languages, such languages should be removed from valid lexeme languages.

Also, "fixing" this issue do more harm than it worthes - user will see two spelling variants with same name but different codes, and will be confused for which should be used.

Change #1105700 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Remove $additionalLocalizedLanguages / wikibase-lexeme-language-name-*

https://gerrit.wikimedia.org/r/1105700

But instead of displaying English language names of such languages, such languages should be removed from valid lexeme languages.

That still doesn’t make it the same task.

Also, "fixing" this issue do more harm than it worthes - user will see two spelling variants with same name but different codes, and will be confused for which should be used.

I’m not convinced that showing missing message keys is better, but that sounds like a product question to me, so CC @Arian_Bozorg @Lydia_Pintscher. For now, the above change was merged to ensure that people don’t keep translating the obsolete messages over the holidays; the next code deployment will only happen after the current deployment freeze is over, so we have a bit of time to adjust the handling of these language codes if necessary.

To be sure: What remains now is not offering deprecated language codes in the menu, is that correct? (The same goes for the language selector for Glosses.) Is that correct?

To be sure: What remains now is not offering deprecated language codes in the menu, is that correct? (The same goes for the language selector for Glosses.) Is that correct?

Doing so means removing $additionalTermLanguages (with non-deprecated language codes there be moved to CLDR extension).