Hmm, kind of agree.

'Declined' with prejudice, i.e 'Dropped', as opposed to 'Rejected' but kept for tracking.

The 'Reinstate' labeling suggests an action that could be reversed. Rather than its actual rejection.

I'm not a native speaker; the reinstate naming is meant to refer to the restored original state after you reject/reinstate a delete. I agree it's harder to understand it when you would reinstate an insert. Perhaps add a tooltip to give more information?

There are 116 references to reinstate in the code by now, so renaming the actual UNO command would not be ideal.

(In reply to Miklos Vajna from comment #2)
> I'm not a native speaker; the reinstate naming is meant to refer to the
> restored original state after you reject/reinstate a delete. I agree it's
> harder to understand it when you would reinstate an insert.

The problem is that strings like "Reinstate Track Change" sound like it's the change that's being reinstated (instead of the state of the document). "Reinstate the original state of the document while preserving the change" would be an unambiguous description (if I understand the feature correctly), but that's a bit too long for a UI string. So I wonder if we could have UI strings that are not overly long, but still describe the feature correctly.

> Perhaps add a tooltip to give more information?

We could do that, but let's see first if we could come up with a succinct term.

> There are 116 references to reinstate in the code by now, so renaming the
> actual UNO command would not be ideal.

I think usually when user-facing strings change in LO, the developer-facing names in the code are not changed. But that's really up to the developer(s) to decide.

Thesaurus comes up with repudiate, refuse, decline, discard... but I don't think any other word makes the situation more clear. "Reject and Retain" (isn't this kind of an oxymoron?) sounds good after pondering a while over the topic but I doubt it helps casual users.

(In reply to Heiko Tietze from comment #4)
> Thesaurus comes up with repudiate, refuse, decline, discard... but I don't
> think any other word makes the situation more clear. "Reject and Retain"
> (isn't this kind of an oxymoron?) sounds good after pondering a while over
> the topic but I doubt it helps casual users.

Perhaps "Decline and Retain" would sound less oxymoronic? OTOH, I think there's a point to be made for emphasising the commonalities between "Reject" and the-function-currently-known-as-Reinstate:

"Reject" = Decline the change, restore the document to original state, discard the change.
"Reject and Retain" = Decline the change, restore the document to original state, retain the change.

I think it will be helpful if we use terms that make it clear that the two functions are closely related.

(Caveat: I am basing this comment on the blog post description of the feature)

"Reinstate" is simply an incorrect, and quite confusing description of this action: 

Reinstatement takes something that had been unstated (stripped or deprived of office, rank, state, status), and "instates" it once again (restores its office, rank, state, status).

In our case, we don't have a binary of "with state", "without state", since content can be:

* In the document with a proposition to change it
* A proposition of change to the document
* Non-existent/gone

(and that's ignoring the fact that a change can itself be an addition, deletion, or modification with no addition or deletion)

So, please confirm this bug!

-----

Now, what shall we use instead? 

Definitely not a synonym of "reinstate".

In fact, this action can be achieved by accepting the change, then undoing it while tracking. 

So, here are several ideas, although I'm not thrilled about any of them:

* "Accept then Suggest an Undo"
* "Accept then Suggest Undo"
* "Accept then Undo"
* "Accept & Track Revert"
* "Accept & Track Reversion"
* "Accept & Revert"

THe following suggestions are vague, but - they have the benefit of quite difficult to misinterpret, which is a plus:

* "Invert suggestion"
* "Invert change"
* "Flip to reversion"
* "Invert"

---------------------------

Comments on other suggestions:

(In reply to V Stuart Foote from comment #1)
> 'Declined' with prejudice, i.e 'Dropped', as opposed to 'Rejected' but kept
> for tracking.

Ah, but the change is more accepted than it is declined.

(In reply to Heiko Tietze from comment #4)
> "Reject and Retain" (isn't this kind of an oxymoron?) sounds good
> after pondering a while over the topic but I doubt it helps casual users.

Same point as above: This does not reject the change, it _accepts_ the change. But instead of retaining the accepted change, it


(In reply to Heiko Tietze from comment #4)
> Thesaurus comes up with repudiate, refuse, decline, discard... 

Which is why we definitely should not use any of those :-(


(In reply to Telesto from comment #5)
> Revert 

I think "Invert" captures the semantics better.

> Revive
> Resurrect
> Resuscitate
> 
> Resurrect appears to describe the action pretty well, I think.

But nothing has died! What are you resurrecting? And what does it mean to be "alive" rather than "dead"? We don't use that metaphor anywhere w.r.t. track changes.

> Restore
> Reinstitute

But nothing has been lost. This is too close to being a synonym of reinstate.


(In reply to Tuomas Hietala from comment #7)
> Perhaps "Decline and Retain" would sound less oxymoronic?

Same point as in my replies to Stuart and Heiko: We're not declining, we're accepting. "Decline and Retain" for a proposed change would be a no-op.

> I think it will be helpful if we use terms that make it clear that the two
> functions are closely related.

Disagree. What is now "reinstate" is both similar and opposite to "accept" and to "reject" - depending on whether, after the "reinstate", you accept-all changes or reject-all changes; i.e. whether you think of the proposed document or the unaltered document.


------------------------

Other comments:

(In reply to Miklos Vajna from comment #2)
> Perhaps add a tooltip to give more information?

Definitely, but that should happen regardless.

> There are 116 references to reinstate in the code by now, so renaming the
> actual UNO command would not be ideal.

On the contrary, it's important we do so now, before there are 1160 references to "reinstante".

(In reply to Tuomas Hietala from comment #3)
> I think usually when user-facing strings change in LO, the developer-facing
> names in the code are not changed. But that's really up to the developer(s)
> to decide.

IMNSHO, it's better if this is changed for developers as well, since they are also people and would definitely be confused by this phrase - especially when the UI calls it something different.

Maybe something like: Reject but keep?

(In reply to Telesto from comment #9)
> Maybe something like: Reject but keep?

Again, it's the opposite of what this does. It's "Accept, but suggest not-keeping".

(In reply to Eyal Rozenberg from comment #10)
> Again, it's the opposite of what this does. It's "Accept, but suggest
> not-keeping".

You mentioned this before in comment 8. However don't grasp why you see/ frame it as 'Accept'

Quote; "This action can be achieved by accepting the change, then undoing it while tracking." This is not totally true. If someone else made a change, you accept the change. The record vanishes fro track changes. Undo the change manually by activating Track Changes -> Record and for example retyping the previous.
A) you lose the author of the original change 
B) You didn't truely accept the change; which implied by your action reverting it back manually.

From: https://vmiklos.hu/blog/sw-redline-reinstate.html
... if a proposed insertion or deletion is not wanted, then one can reject it to push back on the proposal. So far such an action left no trace in the document, which is sometimes not wanted. Calling reinstate on a change behaves like reject, but with history: it reinstates the original state, with the rejected change preserved in the document.

OK: you could say: I liked the previous better, you don't fully reject it when using reinstate. You only want to push back on the change. So 'reverse'. Which would be something like 'reverse and perserve (keep latter as a record)

(In reply to Telesto from comment #11)
> A) you lose the author of the original change 
> B) You didn't truely accept the change; which implied by your action
> reverting it back manually.

But you have truly accepted it: After this action, the document has the change applied and integrated. The change back is just a proposal now.

Just another use-case if that helps: I think reinstate isn't too hard to understand if you focus on the delete redline case. A text was proposed to be deleted, so give me a UI which will create the opposite insert redline. A workaround to do this in Word is: reject the delete, select the text, copy, undo, go after the redline, insert. Reinstate is meant to allow not doing this workaround. (And then the opposite for insert, but that's easier to work around.)

I appreciate if the naming of this is tweaked at a UI level and the rest is not changed, so people can start storing the uno command name in document macros, etc.

(In reply to Miklos Vajna from comment #13)

Let me first say that this is quite the useful feature when editing. Thanks :-)

> I think reinstate isn't too hard to
> understand if you focus on the delete redline case. A text was proposed to
> be deleted, so give me a UI which will create the opposite insert redline. A
> workaround to do this in Word is: reject the delete, select the text, copy,
> undo, go after the redline, insert.

But that's the long workaround. The short workaround is: Accept the deletion, type in the deleted text - done.

(Yes, of course for that to happen you need to be able to type it in, so it might not be so easy, but the point is that it's two steps.)

> I appreciate if the naming of this is tweaked at a UI level and the rest is
> not changed, so people can start storing the uno command name in document
> macros, etc.

But that's exactly the reason why the name _should_ be changed, so that people won't start using the wrong name all over the place.

bypass?
pass over?
passthrough?

(In reply to Alfio Littletree from comment #15)
> bypass?
> pass over?
> passthrough?

Can you elaborate on the rationale for those?

(In reply to Eyal Rozenberg from comment #16)
> Can you elaborate on the rationale for those?

Sure. I was thinking the tracking as a path, where the document is driven by its authors.

> > bypass?
> > pass over?
> > passthrough?
 
The document go past the last change. It do not remove the change, simply go ahead, go over the obstacle that was bringing it in a new direction.
The words "over" or "ahead" make me think of many of the comments I read here.

I hope I didn't disturb you, I just wanted to add three proposals to the brainstorming.

Another suggestion:

    Reject but track

This describes how I understand this (very useful) feature: The change is rejected, but the suggested change is tracked. It is not a single word, but still short.

I am among those who think that it will be much better to find a good wording before 25.8 becomes an official version, than changing it later. By "good wording" I mean something that guides the typical user towards the correct understanding of what the feature does.

Code pointer: officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu has the uno command labels visible on the UI. If you search for Reinstate there, you have 3 hits, the strings inside Label and TooltipLabel are the ones to tweak if the UI string is to be reworded.

(In reply to Lars Jødal from comment #18)
> Another suggestion:
> 
>     Reject but track
> 
> This describes how I understand this (very useful) feature: The change is
> rejected, but the suggested change is tracked. It is not a single word, but
> still short.

I think is is the best suggestion so far.

> I am among those who think that it will be much better to find a good
> wording before 25.8 becomes an official version, than changing it later. By
> "good wording" I mean something that guides the typical user towards the
> correct understanding of what the feature does.

+1

(In reply to Tuomas Hietala from comment #20)
> (In reply to Lars Jødal from comment #18)
> > Another suggestion:
> > 
> >     Reject but track
> > 
> > This describes how I understand this (very useful) feature: The change is
> > rejected, but the suggested change is tracked. It is not a single word, but
> > still short.
>
> I think is is the best suggestion so far.

Strongly disagree. 

Remember: "Rejection" or "Acceptance" of changes are actions which vanishes a proposed ("tracked") change. If the change is accepted - the underlying, untracked, document changes; if the change is rejected - the underlying document does not change.

The action we're discussing is an _acceptance_, not a _rejection_. After the acceptance, a reversion is introduced as a tracked change. 

"Reject but track" would mean a NO-OP.

Created attachment 201313 [details]
Small text file containing a line with track-changes showing both deleted and added text

(In reply to Eyal Rozenberg from comment #21)

> The action we're discussing is an _acceptance_, not a _rejection_. After the
> acceptance, a reversion is introduced as a tracked change. 

In which way is the action an acceptance? The action of "Reinstate" (as it is still called) is to reject a change made by someone else, but instead of the change simply vanishing (normal rejection), a track of the change is kept:

- Text that was suggested deleted appears as both deleted and inserted (rather than just being written unchanged, as would be the case for a normal rejection).

- Text that was suggested inserted appears as deleted (rather than just disappearing).

In both cases, if the result is afterwards accepted, the text will go back to original, i.e., to what it would be like if the changes had simply been rejected with normal Rejection. Thus, the text ends up with the changes rejected, not with the changes accepted.

Put another way: Reinstate + Accept = Reject

Attachment 201313 [details] contains a small test file to experiment with: The text includes suggested changes by someone else (me), suitable for a check of the Reinstate function. LO 25.8.beta1 is available as a suitable version to test with.

(In reply to Lars Jødal from comment #23)
> In which way is the action an acceptance? The action of "Reinstate" (as it
> is still called) is to reject a change made by someone else

Again, no. When you reject a change, the non-tracked document (the baseline if you will), does not change.

When you accept a change, the non-tracked document (the baseline) does change. And this is indeed what happens with "reinstate".

Tuomas, what do you think? Looks like we have some agreement to the latest suggestion but Eyal claims it is not correct, yet the action is neither accept nor reject.

Since only a few days are left until string freeze we may keep either "reinstate" or go with the potentially wrong term. We could also involve more l10n people.

(In reply to Eyal Rozenberg from comment #24)
> (In reply to Lars Jødal from comment #23)
> > In which way is the action an acceptance? The action of "Reinstate" (as it
> > is still called) is to reject a change made by someone else
> 
> Again, no. When you reject a change, the non-tracked document (the baseline
> if you will), does not change.
> 
> When you accept a change, the non-tracked document (the baseline) does
> change. And this is indeed what happens with "reinstate".


Maybe we use words differently. Here comes an example to talk from. To keep things simple here in ASCII, the example considers only insertion of text followed by Reinstate, not deletion of text followed by Reinstate

Example:

baseline: "Hello World"

baseline + tracked change: "Hello, this is a great World" (change-tracking shows ", this is a great" as inserted text)

Accept: "Hello, this is a great World" = changed baseline (the change is no longer tracked)

Reject: "Hello World" = baseline

Reinstate: "Hello[, this is a great] World" = baseline + tracked rejection (text in [] appears as deleted text) 

Reinstate + Accept: "Hello World" = baseline

(End of example)

I agree that Reinstate alone does not return the text to the baseline. But I do not agree that it is comparable to accept. There is a track showing what was suggested - but NOT accepted - as a change. Thus, the only change to the baseline is a track-change. If the track-change is accepted, we are back to baseline.

(For deleted text, Reinstate will show double track-change: the text as deleted and as inserted. Again, the combined effect is to go back to baseline: Reinstate + Accept = baseline)

Therefore, the term "Reject but track" still seems to me to describe the effect of the "Reinstate" function - but the term is of course only a good choice if others can agree.

> To keep things simple here in ASCII, the example considers only insertion of text followed by Reinstate, not deletion of text followed by Reinstate

If we want to simplify the scope to find a better term, I would suggest to focus on "delete, followed by reinstate". That's the primary use-case: instead of the "accept, select, copy, undo, go to the right, paste" workaround, now you can now just press reinstate on a deletion.

I find the insert, then reinstate part less exciting if we want to point out 1 use-case for this discussion. Thanks.

(In reply to Miklos Vajna from comment #27)
> I find the insert, then reinstate part less exciting if we want to point out
> 1 use-case for this discussion. Thanks.

Okay, here is a similar example with deletion:

baseline: "Hello, wonderful world"

baseline + tracked deletion: "Hello[, wonderful] world" - text in [] is tracked as deleted

Accept: "Hello world"

Reject: "Hello, wonderful world" = baseline

Reinstate: "Hello[, wonderful]{, wonderful} world" - text in [] is tracked as deleted, text in {} as inserted

Reinstate + Accept = "Hello, wonderful world" = baseline

(end of example)

Again, the suggested change (a deletion) is rejected, but there are tracks of what was suggested.

Agreed, if the function had only been about deletion, then "Reinstate" would be a good description. But the function is about changes in general, both deletions and insertions. "Reject but track" is an attempt to find a term that covers both cases.

(In reply to Eyal Rozenberg from comment #21)
> Remember: "Rejection" or "Acceptance" of changes are actions which vanishes
> a proposed ("tracked") change. If the change is accepted - the underlying,
> untracked, document changes; if the change is rejected - the underlying
> document does not change.

I would guess this ("Reject and Accept both make the proposed change vanish, so they're closely related") is the way users typically think about change tracking.

> The action we're discussing is an _acceptance_, not a _rejection_. After the
> acceptance, a reversion is introduced as a tracked change. 

I suppose "Accept, then revert" the would then be the most technically correct description for what happens 'under the hood'. But I don't think it would make sense for the average user who is not a developer or LO power-user.

> "Reject but track" would mean a NO-OP.

The word "but" is not a logical operator. It's a modifier here; we reject the change, BUT with some qualifications: unlike the usual "Reject" function, we keep tracking the change.

OTOH something like "Accept, but revert" would likely sound confusingly contradictory to the average user; a bit like "paint the fence black, but white".

(In reply to Tuomas Hietala from comment #29)
> I suppose "Accept, then revert" the would then be the most technically
> correct description for what happens

Well, if "accept" is technically correct, that means that "reject" is a (technically)  incorrect description of  what happens... which is why we can't use _that_ in the name.

> 'under the hood'.

Change tracking semantics are not under the hood. They are the mental model we are teaching users about - through the naming of commands, the experimentation with their effects, the Help and so on. If we introduce technically-incorrect notions into users' minds, we'll keep them jumbled instead of helping sort things out.

But with  - because of the tricky nature of this particular command, I would again like us to consider the third alternative, or set of alternatives:

* "Invert suggestion"
* "Invert change"
* "Flip to reversion"
* "Invert"

these may seem less intuitive to many. But - that is not a bad thing, because:

* It relates this command has a complex nature
* It prevents misunderstading I (nothing "technically incorrect")
* It prevents misunderstading II (since you are unlikely to make a wrong guess about what it does)
* It indicates the "self-inverting" nature of the command, i.e. it clarifies that if you apply it twice it is as though you never applied it at all.

(In reply to Tuomas Hietala from comment #29)
> (In reply to Eyal Rozenberg from comment #21)
> > Remember: "Rejection" or "Acceptance" of changes are actions which vanishes
> > a proposed ("tracked") change. If the change is accepted - the underlying,
> > untracked, document changes; if the change is rejected - the underlying
> > document does not change.
> 
> I would guess this ("Reject and Accept both make the proposed change vanish,
> so they're closely related") is the way users typically think about change
> tracking.

Well, as a (typical?) user, I think of Reject and Accept in this way:

Reject: No, I do not want the change, make the underlying document go back to what it was, i.e., the resulting document should be unchanged compared to the baseline document.

Accept: Yes, I want the change, incorporate it into the underlying document, i.e., the resulting document be changed from the baseline.

In both cases: The document is of course changed in relation to "baseline with tracked changed", and the tracked change (with some representation under the hood) is removed as a tracked change, so the current document will have one less tracked change.

As I understand the idea behind, and use of, Reinstate, it is to be used when one would otherwise use Reject, but wants it to be seen, what was suggested. I can see that under the hood, this must call for quite different code than simply removing the suggested change. As a user, I think of it as "reject the suggested change, but leave a track of what was suggested". Like this:

Reinstate (or what term we end up with): No, I do not want the change, but I want the document with change-tracking to reflect my action (which a simple Rejct will not do). The document is changed from baseline, but in a way such that if I afterwards Accept all changes, then I am back to baseline.


> > The action we're discussing is an _acceptance_, not a _rejection_. After the
> > acceptance, a reversion is introduced as a tracked change. 
> 
> I suppose "Accept, then revert" the would then be the most technically
> correct description for what happens 'under the hood'. But I don't think it
> would make sense for the average user who is not a developer or LO
> power-user.

Trying to understand: In what way is Reinstante an acceptance? Do you mean "acceptance" in the sense that the change still is part of the text (even though it involves text tracked as deleted)? Or...?

Whereever this lands, hopefully it will be in a place that makes sense to the average/typical user (and hopefully without being horrible to look at for the developer).

As a user, I would like to way thank you for developing a very useful feature. Please decide for a name that makes it understandable for me what it is useful for, also if I had not been part of this thread.

(In reply to Lars Jødal from comment #31)
> Well, as a (typical?) user, I think of Reject and Accept in this way:
I can fully sign your statements and don't care whether the text is technically correct. "Reject but track" is easy to understand, much easier than anything else, and you should RTFM anyway ;-).

> Please decide for a name ... also if I had not been part of this thread.
Please not! Your arguments are absolutely valid.

(In reply to Tuomas Hietala from comment #29)
> (In reply to Eyal Rozenberg from comment #21)
> > Remember: "Rejection" or "Acceptance" of changes are actions which vanishes
> > a proposed ("tracked") change. If the change is accepted - the underlying,
> > untracked, document changes; if the change is rejected - the underlying
> > document does not change.
> 
> I would guess this ("Reject and Accept both make the proposed change vanish,
> so they're closely related") is the way users typically think about change
> tracking.

I thought I put "not" in there, but apparently that change got accidentally reverted. :) In other words, I meant to say taht this is NOT how users typically think. Sorry about the confusion!

(In reply to Lars Jødal from comment #31)
> Well, as a (typical?) user, I think of Reject and Accept in this way:
> 
> Reject: No, I do not want the change, make the underlying document go back
> to what it was, i.e., the resulting document should be unchanged compared to
> the baseline document.
> 
> Accept: Yes, I want the change, incorporate it into the underlying document,
> i.e., the resulting document be changed from the baseline.
> 
> In both cases: The document is of course changed in relation to "baseline
> with tracked changed", and the tracked change (with some representation
> under the hood) is removed as a tracked change, so the current document will
> have one less tracked change.
> 
> As I understand the idea behind, and use of, Reinstate, it is to be used
> when one would otherwise use Reject, but wants it to be seen, what was
> suggested. I can see that under the hood, this must call for quite different
> code than simply removing the suggested change. As a user, I think of it as
> "reject the suggested change, but leave a track of what was suggested". Like
> this:
> 
> Reinstate (or what term we end up with): No, I do not want the change, but I
> want the document with change-tracking to reflect my action (which a simple
> Rejct will not do). The document is changed from baseline, but in a way such
> that if I afterwards Accept all changes, then I am back to baseline.

Yes, I agree with this.

> 
> 
> > > The action we're discussing is an _acceptance_, not a _rejection_. After the
> > > acceptance, a reversion is introduced as a tracked change. 
> > 
> > I suppose "Accept, then revert" the would then be the most technically
> > correct description for what happens 'under the hood'. But I don't think it
> > would make sense for the average user who is not a developer or LO
> > power-user.
> 
> Trying to understand: In what way is Reinstante an acceptance? Do you mean
> "acceptance" in the sense that the change still is part of the text (even
> though it involves text tracked as deleted)? Or...?

So if I understood Eyal's argument correctly, on a technical level Reinstate is something like "Accept followed by revert". But my argument is that it's not necessarily a good idea to expose to the user what happens on technical level, much like we usually talk about "water" instead of "dihydrogen monoxide".

(In reply to Lars Jødal from comment #31)
> As I understand the idea behind, and use of, Reinstate, it is to be used
> when one would otherwise use Reject, but wants it to be seen, what was
> suggested. 

Then - with respect, you misunderstand. "reinstate" is not a more visible reject. It accepts the change into the underlying document, then adds a tracked proposal onto the modified baseline document, which, if accepted, would revert that change.

Another way to think about is that you have two versions of the text:

* baseline
* proposed

and what "reinstate" does is switch the two of them. What had previously been just a proposition, is now the (accepted) baseline; and what had previously been accepted into the baseline, now becomes a mere proposition.


This is not "under the hood"; it is the actual "hood"... It may take a moment to think about, granted, but once you do - it makes perfect sense.

(In reply to Eyal Rozenberg from comment #35)
> (In reply to Lars Jødal from comment #31)
> > As I understand the idea behind, and use of, Reinstate, it is to be used
> > when one would otherwise use Reject, but wants it to be seen, what was
> > suggested. 
> 
> Then - with respect, you misunderstand. "reinstate" is not a more visible
> reject. It accepts the change into the underlying document, then adds a
> tracked proposal onto the modified baseline document, which, if accepted,
> would revert that change.
> 
> Another way to think about is that you have two versions of the text:
> 
> * baseline
> * proposed
> 
> and what "reinstate" does is switch the two of them. What had previously
> been just a proposition, is now the (accepted) baseline; and what had
> previously been accepted into the baseline, now becomes a mere proposition.

These are good terms. As there may have been misunderstanding on the way, I will spell them out a bit, to be sure that we agree on their meaning. In the example from Miklos' posting on the new feature, https://vmiklos.hu/blog/sw-redline-reinstate.html, Bob has written a text, Alice proposes some changes to it, and Bob is not happy with all of them and will used Reinstate (rather than Reject). In this context:

baseline = Bob's original text = resulting text after Reject
proposed = Alice's version of the text = resulting text after Accept

(Hopefully we agree?)

Using these terms, we have for standard Reject and Accept:

Reject: The text goes from proposed to baseline (no track left of proposed text).
Accept: Proposed becomes new baseline (no tracking of changes to original baseline).

Now, how about Reinstate? After Reinstate, the new proposed text (= the resulting text after Accept) corresponds to the original baseline. And the new baseline text (= the resulting text after Reject) corresponds to the proposed text. So yes, the effect of Reinstate can be described as switching baseline and proposed.

A drawback of this description is that it takes some logic thinking to see it. It can also be noted that it does not cover _every_ aspect of the function, as the change-tracking is not simply reverted (it is in some cases, but not in all).

Please allow me to think through the "Reject but track" once more. To me, Reinstate is a tool to use instead of Reject. This makes me see it as an augmented version of Reject: Bob wants to reject Alice's proposal, but in a way that does not just let Alice's proposal disappear completely. After Reinstate, the new baseline (the resulting text if Bob or Alice afterwards uses Reject) is equal to Alice's proposal, yes. However, IMHO it is also correct to describe it as a rejection of Alice's proposal, a rejection that leaves a track of what Alice proposed. Futhermore, I think that "Reject but track" is at least as close as "reverse baseline and proposal" in describing what the user will see on the screen as tracked changes.

As I now see it, it is not a matter of one being right and the other being wrong. Instead, it is a matter of viewpoint:
* Reinstate = reverse what is baseline and what is proposal
* Reinstate = reject the proposal, but keep tracks of it

Or put a bit differently:

* Reinstate: baseline and proposal are switched (in the sense of the result of Reject or Accept)
* Reinstate: proposal is rejected, but a track of proposal is kept

Whatever the viewpoint, the final result will depend on whether Reinstate is followed by Accept or Reject or another Reinstate.

I hope I have described both viewpoints correctly and fairly? Can we agree that it is a matter of viewpoint, not a matter of one description being correct and another description being wrong/misunderstood?

In comment 18, I defined "good wording" as "something that guides the typical user towards the correct understanding of what the feature does." We have at least these wordings to choose among:

* "Reinstate"
* "Invert suggestion"
* "Invert change"
* "Flip to reversion"
* "Invert
* "Reject but track"

My own vote still goes to "Reject but track". What do others think?

(In reply to Lars Jødal from comment #36)
> baseline = Bob's original text = resulting text after Reject
> proposed = Alice's version of the text = resulting text after Accept
> 
> (Hopefully we agree?)

Yes, indeed.

> Please allow me to think through the "Reject but track" once more. To me,
> Reinstate is a tool to use instead of Reject. 

I think this may be the crux of what motivates some of us to suggest this wording. You are thinking (probably): "If I use 'reinstate', and later accept all the changes, it will be as though I had just rejected to begin with; so I can use it instead of just Reject'ing"

(am I correct?)

but there's an extra step in that thought process, which the "reinstate" action does not include, which is the assumption that, eventually, all changes are accepted.

Accepting all changes can be thought of as switching "proposed" and "baseline", then deleting "proposed" (because eventually, to get to a document with no tracked changes, you must keep only the baseline).

when we name the action, we can't assume the extra future action like that. In fact, it could be just the opposite:

"If I use 'reinstate', and later give up on idea of making changes, it will be as though I had just accepted to begin with; so I can use it instead of just accept'ing"

and the question is what one considers to be the "real" document: Is it the baseline, or the baseline-with-all-accepted changes. Your extra presumed step corresponds to the latter option.

I think it is unacceptable. But - instead of trying to insist that the other option is the only legitimate one, I believe we should settle on not "forcing" one view over the other, which is why a focus on the more neutral names seems like the way forward.

(In reply to Eyal Rozenberg from comment #37)
> (In reply to Lars Jødal from comment #36)
> > Please allow me to think through the "Reject but track" once more. To me,
> > Reinstate is a tool to use instead of Reject. 
> 
> I think this may be the crux of what motivates some of us to suggest this
> wording. You are thinking (probably): "If I use 'reinstate', and later
> accept all the changes, it will be as though I had just rejected to begin
> with; so I can use it instead of just Reject'ing"
> 
> (am I correct?)

You are partly correct. Yes, I will use Reinstate (under whatever name it ends up with) to indicate that my intention is that the text should end up as if I had used Reject. But I will know that text is _not_ yet final - if it was for the final version, I would use Reject. So no, I will not assume that my Reinstate is how things necessarily end.

Suppose that I am writing a paper together with Alice (putting me in the role of Bob from Miklos' example). I am not happy with Alice's proposed change. If I want to simply decide, "this is the way it is!", there is really no reason to use Reinstate - I can simple use Reject (and maybe send Alice a note that the case is closed). 

But if I consider this still a draft, I can use Reinstate instead of Reject. I _propose_ a rejection of her proposal. In the resulting text, my version will be "on top" in the sense that Accept will end up with my versions. Nothing strange in that: Accept chooses the text in the version that the last person working on the document would like it. However, I will know that if I return the document to Alice, she may make further changes, such as Reject'ing or Reinstate'ing my change to her change.

Of course, I _could_ use the Reinstate feature just to let Alice know which changes I disagreed with. In that case, I could Reinstate, send Alice a copy ("Don't work on it, it's just for information, I decide, and this is how it's goging to be!"), and then Accept. That is a possible use of Reinstate. But that would be a rather limited use of a feature with much broader capabilities for co-working on a document.

> But - instead of trying to insist that the other
> option is the only legitimate one, I believe we should settle on not
> "forcing" one view over the other, which is why a focus on the more neutral
> names seems like the way forward.

Fine with me, if we can find one. I am all for finding a wording that satisfies:
* The wording is understandable to the typical user (i.e., the user will understand what the feature does, not be confused or misunderstand).
* It is naturally connected to the existing Reject/Accept features.
* There is overall agreement among those who comment here.

My best shot has been "Reject but track", but it fails at least on the last point. Who has a better suggestion?

(In reply to Lars Jødal from comment #38)
> Fine with me, if we can find one. I am all for finding a wording that
> satisfies:
> * The wording is understandable to the typical user (i.e., the user will
> understand what the feature does, not be confused or misunderstand).
> * It is naturally connected to the existing Reject/Accept features.
> * There is overall agreement among those who comment here.
> 
> My best shot has been "Reject but track", but it fails at least on the last
> point. Who has a better suggestion?

That fails all three of your criteria, because:

* This will not allow users to understand what the feature does (as - that is just not what it does), and will certainly confuse them, as
* It conflicts with the semantics of the Reject and Accept features, so its connection to them is unnatural.
* There is staunch resistance to it.

Suggestions from my first group, e.g. "Accept & Track Reversion", "Accept & Suggest Reversion" meet the second criterion; don't meet the third criterion; and I believe they also meet the first criterion, but I suppose others might not think so.


I doubt we will be able to find something that meets the first criterion fully, since it is easy to mis-characterize or confuse this feature. I would rather we relax it from "understndable" to "hard to misunderstand". If we do that, I believe that the more 'neutral' set of suggestions, the one without the words Accept nor Reject, could meet all three criteria if we show some flexibility.

I didn't read all the comments into extenso. So might overlooked something. 
I see two cases.

A) Bob inserts XYZ. Alice opposes (mental state), but wants to keep it for further discussion.

Manual steps: Alice accepts the change. Turns track changes ON. Deleted the insertion from Bob 

Essence: Opposing against insertion implies rejection. So reject insertion, but keep. It's not a full fledged rejection (yet). Baseline is changed.

------

B) Bob deletes a XYZ, Alice opposes (mentally), but wants to keep it for further discussion. 

Manual steps: Alice rejects the change. Turns track changes ON. Re-types XYZ

Essence: Opposing against deletion implies rejection. So reject deletion, but keep it for now. It's not a full fledged rejection (yet). Baseline is changed.

----
The definition of Reject at comment 7 is to strict for me. 
"Reject" = Decline the change, restore the document to original state, discard the change.

The button could be called something like: Oppose change? The label doesn't describe what will happen. So it's not totally self-explaining on first use. However it prevents the use of Reject or Accept.

"Oppose change" could be a good choice.

(In reply to Telesto from comment #40)
> A) Bob inserts XYZ. Alice opposes (mental state), but wants to keep it for
> further discussion.
> 
> Manual steps: Alice accepts the change. Turns track changes ON. Deleted the
> insertion from Bob 
> 
> Essence: Opposing against insertion implies rejection. So reject insertion,
> but keep. It's not a full fledged rejection (yet). Baseline is changed.

This scenario is one where "reinstate" would _not_ be used. That is because if Alice opposed the change, she would not introduce it into the baseline document. Introduction into the baseline document means that if there is no agreement on further changes - the change is final. So, in your example, Alice would either Reject (if she has the authority); or keep Bob's change as tracked, making a comment perhaps.

I believe you are sharing the false assumption that tracked changes are eventually all accepted; they are not. When you are a single person working on a document, you could make that assumption, but once others are involved (and even more so, in a formal setting like contract negotiations) - you absolutely can't.

(In reply to Lars Jødal from comment #41)
> "Oppose change" could be a good choice.

Lars, suppose someone sends you a letter asking you pay them a million dollars. Now, you send them the money, but also send a letter asking that they pay you a million dollars.

Have you "opposed" the demand?

(In reply to Eyal Rozenberg from comment #42)
> (In reply to Telesto from comment #40)
> > A) Bob inserts XYZ. Alice opposes (mental state), but wants to keep it for
> > further discussion.
> > 
> > Manual steps: Alice accepts the change. Turns track changes ON. Deleted the
> > insertion from Bob 
> > 
> > Essence: Opposing against insertion implies rejection. So reject insertion,
> > but keep. It's not a full fledged rejection (yet). Baseline is changed.
> 
> This scenario is one where "reinstate" would _not_ be used. That is because
> if Alice opposed the change, she would not introduce it into the baseline
> document. Introduction into the baseline document means that if there is no
> agreement on further changes - the change is final. So, in your example,
> Alice would either Reject (if she has the authority); or keep Bob's change
> as tracked, making a comment perhaps.

I) I might have misused phrase baseline
II) Do you mean that case C 4 (below) shouldn't be used or exist in a proper workflow. Instead a comment should be made? 

Example borrowed from comment 26

A) baseline: "Hello World"

B) Insertion by BOB: ", this is a great" with track changes ON. Result: "Hello, this is a great World" (change-tracking shows ", this is a great" as inserted text)

C) Options for Alice

1) Accept: "Hello, this is a great World" = changed baseline (the change is no longer tracked)
2) Reject: "Hello World" = baseline
3) Do nothing; Nor accept; nor reject
4) Reinstate: "Hello[, this is a great] World" = baseline + tracked rejection by Alice (text in [] appears as deleted text).

(In reply to Eyal Rozenberg from comment #42)
> (In reply to Lars Jødal from comment #41)
> > "Oppose change" could be a good choice.
> 
> Lars, suppose someone sends you a letter asking you pay them a million
> dollars. Now, you send them the money, but also send a letter asking that
> they pay you a million dollars.
> 
> Have you "opposed" the demand?

No, I would just have acted silly :-)

Seriously, I do not think this correponds to Reinstate, even if we go from acting on the text to acting in real life.

Suppose somebody sends me a letter with a proposed command: "Please send us a million dollars."

1) Accept as action: My response is to send a million dollars.

2) Reject as action: My response is to return a blank piece of paper.

3) Reinstate as action: My response is to return the letter with the text crossed out.

And yes, I would consider option 3 (one way of) opposing the demand.

(Regarding assumptions: By choosing option 3, I do not not assume that my out-crossing is accepted. They may choose to rub out my out-crossing and return the demand once more. If I choose option 2, they will have to write the text again from scratch to make the demand again - if they even recognize the blank piece of paper as their rejected demand.)

(In reply to Telesto from comment #43)
> I) I might have misused phrase baseline

baseline (as we've used it here) = the document without the tracked changes (i.e. what you would get if all tracked changes were rejected).

> II) Do you mean that case C 4 (below) shouldn't be used or exist in a proper
> workflow. Instead a comment should be made? 
>
> Example borrowed from comment 26
> 
> A) baseline: "Hello World"
> 
> B) Insertion by BOB: ", this is a great" with track changes ON. Result:
> "Hello, this is a great World" (change-tracking shows ", this is a great" as
> inserted text)

No, the result is "Hello World", with a suggestion of an addition ", this is great". And I stress this phrasing, because the baseline is what is already agreed upon, while tracked changes are just suggestions or proposals.

> C) Options for Alice
> 
> 1) Accept: "Hello, this is a great World" = changed baseline (the change is
> no longer tracked)
> 2) Reject: "Hello World" = baseline
> 3) Do nothing; Nor accept; nor reject
> 4) Reinstate: "Hello[, this is a great] World" = baseline + tracked
> rejection by Alice (text in [] appears as deleted text).

No, that's not the result of option (4.). The result would be: "Hello, this is a great World", with a suggestion to remove the ", this is a great".

So, like  I said above - Alice would certainly not choose option (4.) if she opposes the change. Should would choose (2.) if she has the authority, or (3.) + add a comment about her objection.

(In reply to Eyal Rozenberg from comment #45)
> baseline (as we've used it here) = the document without the tracked changes
> (i.e. what you would get if all tracked changes were rejected).

A well, I did understand baseline (as original document) prior to any track-changes. Not as "what you would get if all tracked changes were rejected"

Example with your definition:
A) baseline: "Hello World" (initial document, without track changes)
B) Bob: Deletion of "World" with track changes ON. Result: Hello.
Baseline = Hello World (Reject deletion = baseline)
C) Alice presses 'reinstate' with track changes ON: Hello World. Deletion becomes Insertion. Baseline = "Hello" (when Reject insertion). 

I don't think Alice intended to change "baseline" to "Hello". The goal of Alice: reinstates the original state, with the rejected change preserved in the document.
(https://vmiklos.hu/blog/sw-redline-reinstate.html)

Or I'm I overlooking something?

(In reply to Telesto from comment #46)
> A well, I did understand baseline (as original document) prior to any
> track-changes.

That's actually the same thing. If you reject all the changes, you get the document prior to any tracked changes being made. Unless I've now misunderstood you somehow...

> Example with your definition:
> A) baseline: "Hello World" (initial document, without track changes)
> B) Bob: Deletion of "World" with track changes ON. Result: Hello.
> Baseline = Hello World (Reject deletion = baseline)

"Hello" is not the result. It is a proposal.

> C) Alice presses 'reinstate' with track changes ON: Hello World. Deletion
> becomes Insertion. Baseline = "Hello" (when Reject insertion). 

The baseline is "Hello" without your parenthesized qualifications.

> 
> I don't think Alice intended to change "baseline" to "Hello".

If she didn't intend to change the baseline - then she made a mistake, because - like you've noticed - she did do just that. And this is why we should absolutely not call this command "reinstate" or "reject and track", because that might convince her to to do so, which she really shouldn't.

> The goal of Alice: reinstates the original state
> 
> Or I'm I overlooking something?

The point of this bug :-(

To "reinstate the original state", we don't need to do anything: The document baseline is the original state, and it needs no reinstatement. (Or if you mean - do away with the proposed changes - that's a Reject All). This command does something else.

(In reply to Eyal Rozenberg from comment #47)
> > I don't think Alice intended to change "baseline" to "Hello".
> 
> If she didn't intend to change the baseline - then she made a mistake,
> because - like you've noticed - she did do just that. And this is why we
> should absolutely not call this command "reinstate" or "reject and track",
> because that might convince her to to do so, which she really shouldn't.

I always understood the intention of reinstate to be: Alice rejects the suggestion from Bob of deletion of XYZ to 'restore' the previous state ("baseline") but to make Bob aware that you rejected the deletion. So the text being reintroduced as insertion. Alice reinstatement is not simply a suggestion, see truly rejected the deletion from Bob. The insertion is only a service to Bob, so Bob can take notice

But if you're say baseline supposed to be equal to reject all the changes, then we are discussing design of the feature as such, I think. Not simply the label

We have discussed quite a bit how the text is changed with Accept, Reject and Reinstate. Here I will instead focus on what the use of the functions are.

Let's assume Alice has written a text (baseline). Bob has made a tracked change, and Alice is now looking at the text (baseline with proposed change). In which situation will Alice use each of the three functions?

Accept: Alice is happy about the change, and it becomes incorporated as part of a new baseline. Case closed.

Reject: Alice is not happy about the change, and she decides that it should not be part of the text. Baseline unchanged, case closed.

Reinstate: Alice is not happy about the change, but instead of just deciding, she uses Reinstate to produce a text that contains tracks of the proposed change. _If_ Accept is used on the text after Reinstate, the result will correspond to Reject (unchanged baseline). But the case is not closed, and Bob has the possibility of editing the change futher (Reject, Reinstate, rewriting...).

(If Bob uses Reject after Alices Reinstate, the new baseline will correspond to Accept'ing Bob's change, and if Bob uses Reinstate on top of Alice's Reinstate, Bob's proposed change is again a proposed change. The point is that the outcome has not been decided yet, even though Alice has indicated that she does not like the change.)

Can we agree that this scenario describes reasonable use of Reinstate (as well as Accept and Reject)?

For a short label, we are not likely to find a term that is 100% unambiguosly clear, so I suggest we settle for a less ambitious goal: A label that makes it reasonably clear to the user, what the "Reinstate" button on the screen is useful for.

If we change nothing, the label remains Reinstate. As written in earlier comments, I can see the reasoning behind this label, especially for deletions, but the basis of this bug thread is that it is not clear enough.

From earlier comments, we have a number of suggestions. Selecting those that ave been seriously discussed:

Suggestions from comment 30 (and before that, comment 8):
* "Invert suggestion"
* "Invert change"
* "Flip to reversion"
* "Invert"

Suggestion from comment 18:
* "Reject but track"

Suggestion from comment 40:
* "Oppose change"

I think these are the ones that have been considered seriously. I take the liberty of also adding one more from comment 5 (also commented on in comment 8):
* "Revert"


My personal evaluation from the perspective of Alice:

Alice is not happy about the change. If she were to decide alone, her action would be Reject. But she may not be in charge, or she is open for discussion (or she is just being polite), so she does not outright Reject it. Instead, she uses a function (Reinstate) after which Bob's change is no longer default choice. 

* This can be described as Alice opposing Bob's change. 
* It can also be described as Alice rejecting Bob's change, but leaving a track of his change.

* From what happens to the text, I see the logic in the suggestions with the word "invert" or "flip". However, as a user in Alice's place, I will be focussing on the text (what does the text say now?) rather than on the change (what is change and what is not?). Therefore, these descriptions would not be obvious to me, even though I might reason into seing why they make logical sense.

* "Revert" is somewhere in the middle. It is not my preferred term, but it makes sense both regarding meaning and regarding what logically happens. If this term is going to be shot down (again), I am not going to fight for it.


In summary: If we do nothing, the term remains "Reinstate". As a user, I would prefer "Oppose change" or "Reject but track", both of which to me reasonably well describes what I/Alice wants to do with the proposed change.

I doubt this will lead to full agreement. But is there a chance that we can reach something closer to agreement? Will we have to settle with a majority decision? Or do we do nothing and simply keeps "Reinstate"?

(In reply to Lars Jødal from comment #49)
> Reinstate: Alice is not happy about the change, but instead of just
> deciding, she uses Reinstate to produce a text that contains tracks of the
> proposed change. _If_ Accept is used on the text after Reinstate, the result
> will correspond to Reject (unchanged baseline). But the case is not closed,
> and Bob has the possibility of editing the change futher (Reject, Reinstate,
> rewriting...).

Lars, I'm sorry, but - you're just repeating a mistaken claim from earlier comments. Remember: "reinstate" accepts a change into the baseline, then creates a tracked reversion of the original change, i.e. removes the change from the proposed version of the document. Thus, instead of Bob having to convince Alice to accept his proposal, a "reinstate" would put her in the position of needing to convince Bob to accept her proposal.

So, in this scenario, Alice would certainly _not_ use "reinstate".

> Can we agree that this scenario describes reasonable use of Reinstate (as
> well as Accept and Reject)?

No, it is an _unreasonable_ use of "reinstate".

Moreover, you neglected to include my first set of proposals, which is the actual functionality of this command: "Accept and track reversion" (or similar wording).

>  As a user, I
> would prefer "Oppose change" or "Reject but track", both of which to me
> reasonably well describes what I/Alice wants to do with the proposed change.

As a user, it is imperative that we not show you the command with that name, since that would reinforce a misperception of its semantics. Alice, who opposes the change, would, in fact, be accepting it, which is really not what she wants to do.

(In reply to Eyal Rozenberg from comment #50)
> (In reply to Lars Jødal from comment #49)
> > Reinstate: Alice is not happy about the change, but instead of just
> > deciding, she uses Reinstate to produce a text that contains tracks of the
> > proposed change. _If_ Accept is used on the text after Reinstate, the result
> > will correspond to Reject (unchanged baseline). But the case is not closed,
> > and Bob has the possibility of editing the change futher (Reject, Reinstate,
> > rewriting...).
> 
> Lars, I'm sorry, but - you're just repeating a mistaken claim from earlier
> comments. Remember: "reinstate" accepts a change into the baseline, then
> creates a tracked reversion of the original change, i.e. removes the change
> from the proposed version of the document. Thus, instead of Bob having to
> convince Alice to accept his proposal, a "reinstate" would put her in the
> position of needing to convince Bob to accept her proposal.
> 
> So, in this scenario, Alice would certainly _not_ use "reinstate".

Eyal, I'm sorry too, but I disagree. Having once more checked the functionality of using Reinstate (e.g. on the test file attachment 201313 [details]), I maintain that this is a case where Reinstate could be very useful for Alice for the purpose I describe.

As I see it: If Bob has made a deletion change, then Reinstate will add the deleted text (tracked). If Bob has made an insertion change, then Reinstate will delete the inserted change (tracked). In both cases, if Accept is used after Reinstate, the text will be back to Alice's original text. So by using Reinstate, Alice is presenting a text that she hopes will end up as Accept'ed (in which case the text will be beack to her original text), but she has not closed the mattter.


We seem to be at the heart of the matter: Is my description/descriptions above relevant for using Reinstate (as I think), or is my description based on a misunderstanding of Reinstate (as Eyal thinks)?

Eyal and I disagrees on the answer to that question. What do others think?

(In reply to Eyal Rozenberg from comment #50)
> Remember: "reinstate" accepts a change into the baseline, then
> creates a tracked reversion of the original change, i.e. removes the change
> from the proposed version of the document. 

Well I made a mistake in comment 46. Baseline is unchanged by reinstate. 
Reinstate re-inserts the text (Alice) but also keeps the deletion from Bob. Pressing reject all will delete both. The insertion from Alice as the deletion from Bob.

(In reply to Telesto from comment #52)
> (In reply to Eyal Rozenberg from comment #50)
> > Remember: "reinstate" accepts a change into the baseline, then
> > creates a tracked reversion of the original change, i.e. removes the change
> > from the proposed version of the document. 
> 
> Well I made a mistake in comment 46. Baseline is unchanged by reinstate. 
> Reinstate re-inserts the text (Alice) but also keeps the deletion from Bob.
> Pressing reject all will delete both. The insertion from Alice as the
> deletion from Bob.

I agree that baseline is unchanged by reinstate. If "Reject all" is used upon a text with changes and reinstated changes, then we are back to the original text from before any changes (baseline). This holds for both reinstated deletions and reinstated insertions. I just tried it out.

(If "Reject" rather than "Reject all" is used, it will be a two-step process for insertions that have been Reinstate'd: After the first Reject, the text contains the insertion as a tracked insertion, the second Reject brings the text back to original text without the insertion.)

(In reply to Lars Jødal from comment #49)
> From earlier comments, we have a number of suggestions.

(In reply to Eyal Rozenberg from comment #50)
> ...you're just repeating a mistaken claim from earlier comments.
The string freeze comes end of this week and these rather academic questions means we keep "Reinstate", which is obviously as hard to understand as "Reject but track" or "Revert". "Invert" or "Flip" and also "Oppose" are kinda off-topic to me.

Created attachment 201425 [details]
Opening text from Alice's Adventures in Wonderland, with two tracked changes

Here is a better example file. It contains the opening sequence of "Alice's Adventures in Wonderland", along with a few tracked changes, an insertion and a deletion. As the effect of "Reinstate" is not quite the same if you reinstate your own changes, I doctored the LO user data: Alice is the author of the text, Bob made the changes.

Frankly, the proposed changes do no make it a better text. So the person now working on the text (Alice or someone else) may not be happy about the changes. The use of Reinstate for both changes gives a text with changes upon changes, where the default is to go back to the original text: Both "Accept all" and "Reject all" will end up as the orignal text. (Of course, if some changes has been left untouched, "Accept all" will differ from "Reject all" regarding these changes.)

So: The functionality of "Reinstate" makes the original text the default regarding the Reinstate'd change(s). What is a good term for this functionality?

My own favourites remain "Oppose change" or "Reject but track". The suggestion "Revert" (or possibly "Revert change") may be a possibility, too, but is still not my favourite.

(During writing this, Heiko concluded that the discussion is academic and "Reinstate" will be kept. I post this anyway, as a non-academic example - being aware that we are so late that Reinstate is likely to be maintained.)

(In reply to Telesto from comment #52)
> Well I made a mistake in comment 46. Baseline is unchanged by reinstate. 

You are right, I double-checked; the baseline is indeed not changed. And I have to take back my long fiery argument. Now it's time for me to apologize: I'm sorry.

(In reply to Lars Jødal from comment #55)
I'm still undecided about what the best alternative would be.

Reinstate
Objection: 
* Normally, if something is reinstated, it is being restored to a previous state or position.
* Translatable?
* Not direction neutral. How can you reinstate an insertion?

Reverse
Objection: sounds like undo. However, it doesn't undo the deletion. It inserts the deletion again. The end result being: nothing changed.

Invert
Objection: not true 'inversion'. The proposal for deletion is being kept. The deleted text is inserted again

Oppose
Objection: feels loaded. 

Reject but track
Objection: pretty long and the 'but'

Reject and retain
Objection: you don't retain the deletion. You add an insertion next to the deletion

Re-insert:
Objection: not direction neutral: you don't re-insert 'inserted text'. It's being deleted again

Pushback on change
Objection: ?

With Eyal's comment 56 (thanks for posting it!), we seem to actually have a chance of agreement - but agreement will be irrelevant unless we find it fast.

Cutting from Telesto's comment 57, taking out those that did not seem like strong contenders beforehand and which Telesto did not add positive words on:

> Oppose
> Objection: feels loaded. 
> 
> Reject but track
> Objection: pretty long and the 'but'
> 
> Pushback on change
> Objection: ?

It is not clear to me in what way "Oppose" is loaded, especially more loaded than "Pushback (on change)". Of these two, I would still prefer "Oppose"/"Oppose change" to "Pushback"/"Pushback on change".

"Reject but track" got at positive response from Toumas (who initiated this report) in comment 20. If Eyal's rebuttal in comment 21 etc. has now been withdrawn, I still think "Reject but track" could be a contender. If "but" is somehow a problem, it might be "Reject with track" to avoid that word...

Eyal, do you have a preference?

Toumas, it has now been some time since comment 20 - any comments at the present stage?

+1, assign "Reject but track" to the 'Label' and 'TooltipLabel' of the Reinstate action as noted in code hint comment 19

https://gerrit.libreoffice.org/c/core/+/186932

.uno:ReinstateTrackedChangeToNext
label: "Reject but Track and Move to Next"
tooltip: "Reject tracked change but keep it and select the next one"

.uno:ReinstateAllTrackedChanges
label: "Reject but Track All"
tooltip: "Reject all tracked changes but keep it"

.uno:ReinstateTrackedChange
label: "Reject but Track"
tooltip: "Reject tracked change but keep it"

Last chance for comments... otherwise I'll submit the patch tomorrow.

(In reply to Heiko Tietze from comment #60)
> https://gerrit.libreoffice.org/c/core/+/186932
> 
> .uno:ReinstateTrackedChangeToNext
> label: "Reject but Track and Move to Next"
> tooltip: "Reject tracked change but keep it and select the next one"
> 
> .uno:ReinstateAllTrackedChanges
> label: "Reject but Track All"
> tooltip: "Reject all tracked changes but keep it"
> 
> .uno:ReinstateTrackedChange
> label: "Reject but Track"
> tooltip: "Reject tracked change but keep it"
> 
> Last chance for comments... otherwise I'll submit the patch tomorrow.

Grammatically, shouldn't it be "them" rather than "it" in the tooltip text for "... All": "Reject all tracked changes but keep them" ?

Otherwise looks good, thanks!

Also thanks to everybody for keeping a good tone in the discussion - sometimes fiery, but never fiendish :-)

PS: If there is going to be a discussion about the uno strings (should they stay "Reinstate" or should they be changed, too, and when?), it is probably best done from a fresh report with reference to this thread.

(In reply to Heiko Tietze from comment #60)
> Last chance for comments... otherwise I'll submit the patch tomorrow.



Two points:

As I was saying before, my comments so far had been based on the wrong assumption that the baseline is changed - which it isn't. However, the other author's proposed changes are also not made to disappear, so - they're not actually rejected.

Given that, I'd think more along the lines of "Propose reversion" or "Tracked reversion". That clarifies there is no Reject (nor Accept), and that the other author's suggestion/proposed change is also not going away.

----

Also, consider the following scenario:

1. Create a new Writer document
2. Enable 'Track Changes'
3. Type "hello"
4. Right-click the word you typed
5. Choose "Reinstate" / "Reject but track"

Result: The word is deleted, and nothing else appears, tracked or otherwise.

Now, it may be the case that changes by _yourself_ should not be reject-but-track'able. But right now, they are. So, something to think about at least.

(In reply to Lars Jødal from comment #58)
> Toumas, it has now been some time since comment 20 - any comments at the
> present stage?

Perhaps we haven't found the perfect name yet, but as time is running out, a choice has to be made. I think "Reject but track" should give users a better idea of what this function does than "Reinstate".

Ideally this should be checked with users beforehand, but that would take a lot more time than we have.

Thanks for discussion and suggestions, everyone! Hopefully in the future we could have these discussions ahead of time when a new feature with new terminology is about to be introduced.

Thanks Heiko for improving the uno command labels.

Tuomas: if the feedback is that it needs more time, the libreoffice-25-8 config can be also tweaked to just hide the new function so it'll show up only on master to get more time. But I assume the proposed change from Heiko addresses the immediate need.

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7aae69d7c9fd4133234600a232cfc30785cc808c

Resolves tdf#166723 - Misleading use of the word "reinstate"

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/7de4a9f479018e3bd8c4b59cb57b2870195edf18

Resolves tdf#166723 - Misleading use of the word "reinstate"

It will be available in 25.8.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Great, we got it in time!

(In reply to Miklos Vajna from comment #64)
> Tuomas: if the feedback is that it needs more time, the libreoffice-25-8
> config can be also tweaked to just hide the new function so it'll show up
> only on master to get more time. But I assume the proposed change from Heiko
> addresses the immediate need.

That could be a possibility, but do we need it? IMHO, "Reject but track" does in practice cover the meaning for the user:

* Reject: The change is rejected (in the ususal sense of the word) and is gone.

* Reject but Track: The change is rejected, but a track is left of it, so it is not just gone. Other users still have the possibility to use the track to put the original change back in operation, but the default will be that it ends up gone. As noted before, the change will end up gone (Reject'ed) _both_ as a result of Accept All and as a result of Reject All.

Indeed, the action "Reject but Track" differs from the action "Reject". To the user, that should be clear - why otherwise have more than just "Reject"?

Regarding the behaviour of "Reject but Track" on your own change, that is now discussed in bug 167194. The suggestion there does not involve the term, but whether the function should at all be allowed in that case - but let's keep that discussion to that report.

Still on this track:

It seems that string #xPgHS in Weblate was missed:

    Reinstate change: $1

I guess that should be:

    Reject but track change: $1

Can the string still be changed, as an overlooked string?

(In reply to Lars Jødal from comment #68)
> Still on this track:
Will submit a patch.
 
> Can the string still be changed, as an overlooked string?
That's too late for 25.8.

The string seems to be used in the undo stack.

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a3df886c5d259777dc88eb5919c56ee028df1298

Related tdf#166723 - Misleading use of the word "reinstate"

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.