|Open||None||T194253 Configure the CI job that runs WikibaseLexeme's browser tests against test wikidata|
|Resolved||Addshore||T168260 Deploy WikibaseLexeme extension on Wikimedia cluster|
|Resolved||Addshore||T191457 Deploy WikibaseLexeme on www.wikidata.org|
|Resolved||Addshore||T191458 Deploy WikibaseLexeme on test.wikidata.org|
|Resolved||Lydia_Pintscher||T168263 WikibaseLexeme functional baseline|
|Resolved||Ladsgroup||T154221 Special:NewLexeme should have validation for language and lexical category|
I believe that it should be done in both places.
As I understood ChangeOp is more (correct me if I'm wrong) Data Access Layer thingy and responsible for persistence: generate Summary and ensure that we won't get inconsistent data in DB.
But in this case, I would say, we want to show a nice message to user that item id he entered in the field simply does not exist (or may be he entered something unparsable, then we can also tell him to check the input).
I think it is different responsibility and should be done separately.
To clarify: Conceptually, ChangeOp does not belong to the persistence layer. They are basically plug-ins to an "interactor". The represent a "modification" to the Entity, and their main purpose is to apply that modification to the data model, after validation. Their secondary duty is to provide a human readable description of the modification. They have nothing to do with storage.
If we have an input constraint "a Lexeme's lexical category must be an existing item", then this is exactly the right place to do it: preserving the logical integrity(*) of the data model is indeed the job of ChangeOps.
(*) Note that these constraints are "soft" in the sense that they are checked on input, but may be broken later - e.g. the referenced Item is deleted. This means that we do not have a strong guarantee that this constraint remains true, but we enforce it for input from users and bots.