Say we have a list of 1 2 3 4, then someone adds a new 1. We need to rename
- 4->5,
- 3->4,
- 2->3,
- 1->2
- Import 1
In that order.
We need to ensure that this works well with the new rename functionality
abi_ | |
Sep 16 2019, 4:47 AM |
F30473636: image.png | |
Sep 26 2019, 10:14 AM |
Say we have a list of 1 2 3 4, then someone adds a new 1. We need to rename
In that order.
We need to ensure that this works well with the new rename functionality
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | abi_ | T196601 Support renames in Special:ManageMessageGroups | |||
Invalid | abi_ | T232967 Detect renames / moves that have ordering dependency |
We need to ensure that this works well with the new rename functionality
Just refusing to process such changes is sufficient for me. They can be handled manually as before.
Did some testing on this,
Initial contents of the language file,
model.nation.state.1=Goa model.nation.state.2=Karanataka model.nation.state.3=Kolkata
Updated content of the language file,
model.nation.state.1=Kerala model.nation.state.2=Goa model.nation.state.3=Karanataka model.nation.state.4=Kolkata
Which then opens this during message group management,
That looks acceptable to me.
When looking for renames, we only look at added or removed messages, not modified messages.
Yes, I think so. Here's how the rename matching is done...
In this case, almost all of these are modifications, and not additions or deletions. Except for the last one in the sequence (model.nation.state.4), that is now a newly added message.
The only time I see an issue happening is if the newly added message content matches that of a deleted message.
As per the message above, we do not need to work on this. Still this was a good case to think through.