In T268689#8036398, @Michael wrote:
- show error if saving a language mis-x- code with a lowercase item id
- this will need adjusting the LexemeTermLanguageValidator as discussed in T268689#6646820
- this should get us ~80% of the benefit of this story
Description
Description
Details
Details
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T268689 Lexeme language code allows both upper and lowercase qids in -x-qid syntax | |||
| Resolved | Lucas_Werkmeister_WMDE | T317863 Only save Lexeme language codes with uppercase item IDs (mis-x-Qid), not lowercase (mis-x-qid) |
Event Timeline
Comment Actions
Change 832616 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] Allow removing terms with invalid language codes
Comment Actions
Change 832617 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] Only allow *-x-Qid language code with uppercase item ID
Comment Actions
Copying part of the second commit message, since it’s kind of a product question / decision:
Lexemes with now-invalid language codes can still be used and mostly edited, but trying to edit the lemmas of a lexeme with a now-invalid lemma will fail unless the invalid lemma is removed in the same edit, even if the edit doesn’t touch the lemma in the invalid language. In forms, on the other hand, representations with other language codes can still be edited regardless of whether there is a representation with an invalid language code. (In sense glosses, *-x-Qid language codes aren’t valid to begin with.) […] This could be changed either way if we wanted to.
Comment Actions
Thx, Lucas! After we implement the normalization part of the task, this should all lead to the same outcome, right? So no need to change things.
In case we plan a preliminary release of only the first part of the task, then fewer errors (the forms way) would be preferable to not confuse people.
Comment Actions
Thx, Lucas! After we implement the normalization part of the task, this should all lead to the same outcome, right? So no need to change things.
I suppose so, yes.
In case we plan a preliminary release of only the first part of the task, then fewer errors (the forms way) would be preferable to not confuse people.
Well, right now I didn’t make the behavior configurable in the Gerrit change, so it would probably roll out in the train on its own.
Comment Actions
Change 832967 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] Only send edited lemmas when editing lexeme header
Comment Actions
Change 832616 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Allow removing terms with invalid language codes
Comment Actions
Change 832967 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Only send edited lemmas when editing lexeme header
Comment Actions
Change 832617 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Only allow *-x-Qid language code with uppercase item ID
Comment Actions
! In T317863#8241564, @Lucas_Werkmeister_WMDE wrote:
Lexemes with now-invalid language codes can still be used and mostly edited, but trying to edit the lemmas of a lexeme with a now-invalid lemma will fail unless the invalid lemma is removed in the same edit, even if the edit doesn’t touch the lemma in the invalid language. In forms, on the other hand, representations with other language codes can still be edited regardless of whether there is a representation with an invalid language code. (In sense glosses, *-x-Qid language codes aren’t valid to begin with.) […] This could be changed either way if we wanted to.
Hi @Lucas_Werkmeister_WMDE, as we are not doing the normalization after all, this inconsistency becomes more relevant again: We should make the forms behavior (with fewer errors for users) the behavior in all cases. Otherwise this may be confusing for people, correct? How would we make this happen? Should we open this task again or should we create a new task for this change?