I'd like to suggest a change to infer the spelling variants from P‌220 or P3‌05 per T284882.

Thanks. Poked Daniel and Denny there for input as I seem to remember they had good reasons for the current state but can't quite puzzle it together anymore.

In T298142#7585471, @Mahir256 wrote:

I'd like to suggest a change to infer the spelling variants from P‌220 or P3‌05 per T284882.

The dedicated property would be https://www.wikidata.org/wiki/Property:P9753

We should also consider no matter what property we use, the values are not always language codes supported by Wikidata. See T209282: Error when creating lexemes in languages which have an unsupported ISO 639-1 code

@Erdinc_Ciftci_WMDE can you have a look at the copy of the warning message?

TODO Lydia: think through which Property to use some more.

(Some background) possible language code scenarios

• Valid language code → No spelling variant lookup, no warning message.
• Invalid language code (meaning the retrieved code is not in the list of allowed codes) → Yes spelling variant lookup, yes warning message.
• No language code → Yes spelling variant lookup, no warning message.
• No language Item selected → No spelling variant lookup, no warning message.
• Loading language code request -> No spelling variant lookup, no warning message, loading indicator shown (@Erdinc_Ciftci_WMDE Are there mocks for this state? Should this be part of this task @Lydia_Pintscher?).

Task Breakdown Notes:

• We have the list of lang codes that are allowed as spelling variants.
• Field validation and error / warning message display is embedded in the Wikit lookup component.
• If the language P218 statement's value contains incorrect and valid data, you will not receive a warning. If it is incorrect and invalid, a warning will be shown.
• If the P218 statement includes more than one value, the application will use the first best ranked value (@Lydia_Pintscher does that chime correctly?).

Potential Plan of Action:

1. Either:
   • Pass down the wgLexemeLanguageCodePropertyId to the 'new-lexeme-special-page' application via the config. [TASK TBW by @guergana.tzatchkova]
     
     And in parallel:
   • T305539 Write a repository implementation (in the vue application's data-access directory) to retrieve the language code property data from the API.
2. T305542 Add an action and event handler to call the API and retrieve the language code from the repository.

In parallel

• T305535 Extend the wbgetclaims action API module to support 'Best Ranked' statements in addition to the currently available filters (@Lydia_Pintscher does that sound a good investment for our users?)

In parallel

• T305546 Add the i18n message to the WikibaseLexeme messages list in en.json and qqq.json. and pass them down into the vue app via the ResourceLoader.

If the P218 statement includes more than one value, the application will use the first best ranked value (@Lydia_Pintscher does that chime correctly?).

The current implementation almost uses the first best-rank statement, except that it falls back to deprecated-rank statements if there are no preferred- or normal-rank ones, whereas our usual “best rank” logic never uses deprecated-rank statements even if they’re the only ones that exist. The code was introduced in April 2017 without any product involvement being recorded as far as I can see (no attached Phabricator task, only technical comments), so it’s not clear if the inclusion of deprecated statements is intentional or not.

(Also, I think the current implementation will crash if the first best-rank statement is a somevalue or novalue one.)

@Lydia_Pintscher What should happen if the best-rank P218 statement has unknown value, or no value? (Currently, there are 11 items with novalue P218, and no items with somevalue P218.)

(The code in the old special page just crashes in that case, if I’m not mistaken, in case you were wondering.)

😬 I was indeed wondering 😆

Can we treat it as if no statement was present? So in essence show the spelling variant selector.

@Michael and I were thinking that it might make sense to treat novalue like a missing statement, but somevalue like an invalid language code (e.g. P218=foobarbaz), so the latter would show the spelling variant selector but also an error message. Though I’m not sure if the invalid language code is supposed to be included in that message – if yes, then it’s unclear what somevalue would look like.

Ok let's go with what you proposed then.
As for the message: We can keep the error message something generic like "We could not read the statement for the language code from the Item foo" and then link the statement?

I forgot that the task description already has the message copy – “This Item has an unrecognized language code. Please select one below.” should work for both cases, I think.

Doh! Yes ;-)