Confirmed with:
LOdev 3.5.3rc1+ 
Build ID: 51648779-22e3d74-d554af7
Windows 7 Professional SP1 64 bit

LibreOffice 3.5.2.2
Build ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45
Running on Windows 7 Pro, SP1, 64 bit edition

The results were reproducible.

The bug is still not corrected (Libre Office 4.3)

I recorded video so effects of the bug could be easily understood: 

https://www.youtube.com/watch?v=n3n5P5Aqu44&feature=youtu.be

Reproducible in 4.4.3.2.

If you right click anywhere in a paragraph and apply Sentence case then the whole paragraph is affected.  All of the other Change Case options either affect the word that has the cursor or a selection.

From the help:  Changes the first letter of the selected western characters to an upper-case character.

The bug is still present in LibreOffice 5.4.1.2.

The only thing that has changed is that the relevant menu entry has moved to "Format->Text->Sentence case".

Tested under Linux (OpenSUSE Tumbleweed), using the official LibreOffice binaries.

Still present in 5.4.1.2. Apart from that, the whole change case code should be checked. Applying Sentence case to selected text in lower case will not change the first letter following a full stop to upper case. There are several other irregularities.

The bug is still present on Version 6.1.2.1

Versão: 6.1.2.1 (x64)
ID de compilação: 65905a128db06ba48db947242809d14d3f9a93fe
Threads da CPU:4; SO:Windows 10.0; Realizador da interface: padrão; 
Local: pt-BR (pt_BR); Calc: group threaded

*** Bug 120872 has been marked as a duplicate of this bug. ***

*** Bug 120039 has been marked as a duplicate of this bug. ***

*** Bug 120254 has been marked as a duplicate of this bug. ***

Likely needs to be tweaked in the string being passed to caserotate.cxx for ICU lib transliteration.

see 

https://gerrit.libreoffice.org/#/c/59894/

https://gerrit.libreoffice.org/#/c/51696/

*** Bug 120872 has been marked as a duplicate of this bug. ***

*** Bug 121350 has been marked as a duplicate of this bug. ***

(In reply to Dieter Praas from comment #19)
> Can't reproduce it in

Unfortunately it remains to be fixed. And here are STR that still indicate the string handling of selection for ICU filter is wrong:

1. new Writer document
2. add DT -> F3 autotext for the DummyText
3. select the 'h' form "him." ending the first sentence, and capitalize
4. select all but the "Him." of the first sentence "He heard quiet steps behind "
5. cycle the applied ICU Transliteration filter with <Shift>+F3

Watch it cycle. If corrected the "Him." should remain capitalized? 

Currently it still does not.  Rather, the full sentence textrun, rather than the selection/or word, is affected upon cycling to the SENTENCE_CASE transliteration [1].

Imagine that is caused by difference in the "default" string handling for SENTENCE_CASE, by definition no substrings of selection/word? Edit engine seems to expand the selection when SENTENCE_CASE transliteration is applied here [2].

So, while we may not like it--behavior could be considered correct.

=-testing-=
Windows 10 Ent 64-bit en-US with
Version: 6.3.0.0.alpha0+ (x64)
Build ID: ffa5b8a82eab18041bbee4d6914892b82c7801d3
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-12-19_03:24:54
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

-=ref-=
[1] https://opengrok.libreoffice.org/xref/core/unotools/source/i18n/caserotate.cxx
[2] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?r=492ea7e0#2785

(In reply to V Stuart Foote from comment #20)

> Edit engine
> seems to expand the selection when SENTENCE_CASE transliteration is applied
> here [2].
> 
> So, while we may not like it--behavior could be considered correct.
> 

Seems this was intentional to "keep it simple by just capitalizing the first letter or each sentence", and so temporarily expand selection(s) to the full sentence for applying the transliteration.

see https://bz.apache.org/ooo/show_bug.cgi?id=113587#c5

But 9 years on does this need revisit? 

Maybe, since for bug 116315 we've now added the SENTENCE_CASE transliteration to the <Shift>+F3 cycling, meaning more folks will experience this during use.

*** Bug 119495 has been marked as a duplicate of this bug. ***

+1 for @Mike Kaganski

Please note that most users aren't programmers. Their logic is different than the logic of the programmers. So the question is: Whose logic is right? I'd say that as the product is a productivity tool, the logic of the user should take precedence over the logic of the programmer, who may not be aware how a user may use features of the software. Anything that reduces the usability or efficiency of a productivity tool shouod be seen as bad, a show stopper, etc.
We're not playing a game between users and programmers, and nobody should try to win that game by inventing some "logic" so that you can maintain the status quo and "win". Registering a bug, issue or enhancement request is a daunting task for many users, Please remember that.

> So, while we may not like it--behavior could be considered correct.

No, it is NOT correct.  Repeatedly pressing F3 to get to the case you need *destroys* any capitalisation that already existed, and thereby makes this function unusable in many cases.  That is NOT correct.  See the extensive discussion of bug 119495 which has now been closed as a duplicate of this one.

And please... FIX IT!

In fact, I'll repeat some steps to reproduce that I provided on that other bug:

Type the sentence "john smith and joe blow wrote to fred jones.

Now, using Shift-F3 as many times you like and selecting whatever parts of the text you'd like, capitalise the first letter of each name, and only those letters.
If you can do it, I'd like to know how.

(In reply to Philip Rayment from comment #24)
> > So, while we may not like it--behavior could be considered correct.
> 
> No, it is NOT correct.  Repeatedly pressing F3 to get to the case you need
> *destroys* any capitalisation that already existed, and thereby makes this
> function unusable in many cases.

No one discounts that it has undesired effects. 

In comment 21 I've simply pointed to what causes users grief--noting that at the time it was implemented in 2010, the OOo users and developers chose to handle the SENTENCE_CASE transliteration against full sentences--expanding any selection to the include sentence boundary.

It is clear from discussion of the feature, they did not consider that the SENTENCE_CASE would be added to the <Shift>+F3 toggle, and that users applying it from Format menu would "only" use it rationally when they were cleaning up blocks of text. 

It is correct as it was implemented, and behaves programmatically as expected. It simply does not have the additional logic needed to deal with users seeking to apply sentence case selectively--when developed they did not think it would need it, and folks would be better served working with sentences rather than word selections.

Since the <Shift>+F3 case cycle now includes the SENTENCE_CASE transliteration, working with selections consistently becomes more of an issue needing dev attention to remove the annoyance.

Please refrain from insulting others by declaring someone is "playing games" and "tries to win", without even carefully reading what has been said (let alone understand):

(In reply to V Stuart Foote from comment #21)

> Seems this was intentional to "keep it simple by just capitalizing the first
> letter or each sentence", and so temporarily expand selection(s) to the full
> sentence for applying the transliteration.
> 
> see https://bz.apache.org/ooo/show_bug.cgi?id=113587#c5
> 
> *But 9 years on does this need revisit?* 
> 
> Maybe, since for bug 116315 we've now added the SENTENCE_CASE
> transliteration to the <Shift>+F3 cycling, meaning more folks will
> experience this during use.

Secondly, what users like to call "programmer's logic" is always another user's logic, which happens to not fit you, but that was adopted by programmer as an implementation specification. This reflects multitude of ways anything may be used, and there's no way to please everyone. This is what users refuse to accept when they insist that their "logic" (in this context it's the way they use something) is universal. Yes, programmer's choice of specification may be bad in the sense that it doesn't reflects the majority's use case, but that needs proving, and it's not easy (in bug reports, you always see the PoV of those who disagree with the status quo, and those who agree are Just happily use it and don't visit bug reports).

In this case, my "logic" (as user who filed the report, also being a developer) differed from the "logic" adopted by the feature author, who considered multiselection usecase (which I didn't), but didn't consider normalizing pasted chunks of text that had bad case in the source (where author's presumptions doesn't hold).

Now that the feature started to be used in a scenario not meant initially, this became more important.

Mike Kaganski: I am not insulting anybody. I feel insulted by programmes who refuse to consider serious error reports by competent users. And add to the insult by stating that tge cide is correct, implying that the users are stupid.

For a similar case, but for OpenOffice, see this discussion in the OO Issue tracker: https://bz.apache.org/ooo/show_bug.cgi?id=119407

(Orcmid, the last person to post a comment in that discussion, was then a senior staff member of AOO development at Apache.)

We're now several years later, right now I can't test if the bug still exists in AOO, but I'm fairly sure that it does. I rest my case.

> It is correct as it was implemented, and behaves programmatically as expected.
You're probably right, but the issue is what "it" is.  This bug as opened was about how sentence case works.  The problem I see is that bug 119495 has been closed as a duplicate of this bug, but that bug was about sentence case being used in the Shift-F3 cycle.  So "it" now includes the latter.  Perhaps bug 119495 should not have been considered a duplicate, and should have remained open?

> It is clear from discussion of the feature, they did not consider that the SENTENCE_CASE would be added to the <Shift>+F3 toggle...
And to my mind, that is the key problem, because...

> No one discounts that it has undesired effects.
... the result is not just an "undesired effect", but a situation where Shift-F3 is largely UNUSABLE.

Perhaps the quick fix is to remove sentence case from the Shift-F3 cycle so that that is usable again, then come to some agreement about the original issue in this bug and how it can be incorporated into the Shift-F3 cycle without making that unusable.

But maintaining that the way that sentence case works is arguably correct ignores the bigger problem of the Shift-F3 cycle being unusable, and therefore misleads as to the urgency of fixing that clear bug.

(In reply to Philip Rayment from comment #29)
+1

(In reply to Peter Roelofsen from comment #28)
> Mike Kaganski: I am not insulting anybody. I feel insulted by programmes who
> refuse to consider serious error reports by competent users. And add to the
> insult by stating that tge cide is correct, implying that the users are
> stupid.

You show exactly what I said: users believe that they Hold The Truth. They believe that they are Competent Users, and thus what they raise is Serious Errors.

Now let's see this problem again. I reported it while back, when Shift-F3 didn't include this function yet, and so my specific bug report doesn't cover the side effects of the inclusion of it into the Shift-F3. So I believe that bug 119495 is another bug.

And thus let's discuss the original issue here, which both I and Peter Roelofsen raised here and at Apache. Which is affecting what is not selected (I don't tell about ignoring a char after full stop bit from Apache bug, which I cannot repro, and I didn't raise here).

And so now Peter Roelofsen says: "programmes ... refuse to consider serious error reports by competent users" - so he clearly just dismisses the others' opinions. He mentions another opinion of Orcmid as a "proof", and treats all others arguments as "insulting", which is clearly not constructive approach, but a technique to make own PoV look "ultimate truth".

But the original implementation specifically made it work like that, to cover *another user's* demand to be able to mark *parts* of sentences in multi-selection mode, and have the *full sentences* processed. It means that Peter Roelofsen declares that *another user* "stupid" (using his own terminology), not the programmer who implemented that.

Note that I still consider changing the implementation to only handle selection to be the right move; not because I suppose the implementation to be erroneous, but because I believe that change would cover larger set of use cases, and be more compliant with least surprise principle. But I understand that this is arguable; and I will never dismiss another's opinion contradicting mine to be insulting or dismissive, unless that opponent uses unfair argument technologies. Even less will I consider insulting posts that bring the original design bits into the discussion, which allows one to have fuller and better understanding of the picture.

Personally I would consider the seriousness of the problem that Orcmid caller serious as documentation problem [1], where the intended behavior of the function is not described. And then again, this my issue is about choosing if my suggested approach is beneficial to more users than existing approach, nothing more.

[1] https://help.libreoffice.org/latest/en-US/text/swriter/guide/text_capital.html

(In reply to Mike Kaganski from comment #30)
+1

But the original issue as summarized in bug 119495 was clearly a duplicate of this. 

Absent SENTENCE_CASE's default expansion of selection, adding it to the <Shift>+F3 transliteration cycling would have been a non issue.

The non-reset of the mode cycling, with a timer based patch attempt, was issue creep--and arguable as to merit. But IMHO agree a reset upon detecting a selection change/edit cursor movement is probably the way to normalize its behavior.

From UX perspective, honoring the user's selection--eliminating the legacy auto expansion (or reduction) to work with "sentence" runs--is now more urgently needed to close this out as efficiently as possible. 

No need/advantage to reverting bug 116315 that can't be handled with changes needed to make SENTENCE_CASE apply to user selection, rather than to expanded runs between "sentence" breaks as now. 

Dev choice, but the actual refactoring could be ambitious (where is it used and should behavior be user settable in Advanced Configuration) or simple (move SENTENCE_CASE from TransliterationModulesExtra to TransliterationModules, apply to selection only). 

Adjust things here and you fix legitimate corruption of <Shift>+F3 cycling.

The current "Sentence case" logic would make perfect sense in case you select no single character and you expect to change cases of a complete sentence. However, in the case when you invest the effort to select the part of your text, there is no single justifiable reason to extend this to complete sentence. So, there are no two sides to this story; just the one that is currently implemented and the one that should be implemented (in case some developer have time; not requesting anything because I don't use "Sentence case" anymore or SHIFT + F3... I adjusted my behaviour with custom menus and custom shortcuts).  

With the current implementation, we are saying: "Oh, you selected the part of the text, but we believe you should consider the full sentence."

(In reply to V Stuart Foote from comment #31)

Let's discuss the details :-)

1. What should be done when a sentence start is selected, but not to the sentence end? (I'm pretty confident the sentence start here should be capitalized.)
2. What should be done if a sentence end is selected, but not from start? (This one IMO is not that straightforward: we can capitalize the first selected character, or we may skip the sentence; my take would be capitalize first selected character.)
3. What should be done if selection starts in the middle of a word (possibly not the first in a sentence)? We could capitalize first character of the word (again not good for Shift+F3); or first selected character; or skip the sentence. (I'd capitalize first selected character.)
4. What should we do when there's no selection? We could capitalize first character of current word (if any; like UPPERCASE at al work); or current sentence. (My take is Capitalize current sentence.)
5. What should be done with Capitalize Every Word function, that now also expands to whole words, even if only parts are selected? It's not in Shift+F3 IIUC, but it would become inconsistent. (I'd say change it consistently.)
6. Should we only do the change for Word, or for other modules (Calc/Impress/etc) too for consistency? (I'd say yes.)

The way I see it, things are pretty simple: If the user selects a piece of text and asks for something to be done with it, he expects that something to be done with only that piece of text. If the result is not what he expected, his reaction will be "oh, yeah, I should have made a different selection", undo the change and try again. On, the other hand, if that something is done with other parts of the document, the user's reaction could well be "why did this happen? I didn't ask for this", as, e.g., with that A, signifying Amperes, in the first comment.

Thus, if you can fix this issue, please do so, and do it in the simplest possible way, i.e., only applying case changes in the selected text, even if it means introducing a capital letter in the middle of a word. There is no need for LO to try and second-guess the user.

Thanks.

(In reply to Ljiljan from comment #35)
> You select the text and you expect to see changes in
> the selection.    
In most cases, yes, but not always.  For example, it makes little sense to apply sentence text to only part of a sentence, especially part that doesn't involve the start of it.  So it may not be the case you expect to see changes only in the selection in that case.

Mike Kaganski's questions were fair, and your satire was unhelpful.

(In reply to Mike Kaganski from comment #36)
> (In reply to Ljiljan from comment #35)
> 
> I had decided to fix this, and so I found all relevant code and  saw the
> implementation; while thinking of possible reimplementation, I fount it
> useful to ask specific questions, so that the programming decisions would be
> clear and based on user requirements.
> 
> But now you are free to fix this yourself. I'm no more interested in this.

Mike, please don't allow one commenter to put you off this.  I didn't realise that you were planning on fixing this, and I thought your list of questions was just to illustrate the problems rather than seeking feedback that would be taken into account in an actual fix.  I'll have a go at answering your questions in a separate reply.

Let's say I start with this sentence: 

"This is my SENTENCE I wrote as an example to ILLUSTRATE the how the user might use this function [here I intend to put a full stop after changing it to sentence case] and THIS SENTENCE HAS NO PURPOSE AT ALL."

Now, I decide to split this into two sentences. I select this first part expecting to change the first part of the text to sentence case, and then I will put the full stop after "this function" part. But LibreOffice decides to change the complete paragraph, and I did not want the second part to be changed.

In the context of the user stories, this is a real scenario and the current implementation does not help. 

So honouring selection is important. We don't know what user intends to do. Selection helps here, not guessing. That was the point of my satire... not to offend everyone.

(In reply to Mike Kaganski from comment #34)
> (In reply to V Stuart Foote from comment #31)
> 
> Let's discuss the details :-)
> 
> 1. What should be done when a sentence start is selected, but not to the
> sentence end? (I'm pretty confident the sentence start here should be
> capitalized.)
I'd suggest that the sentence start should be capitalised, and the rest of the selection (not sentence) made lower case.
> 2. What should be done if a sentence end is selected, but not from start?
> (This one IMO is not that straightforward: we can capitalize the first
> selected character, or we may skip the sentence; my take would be capitalize
> first selected character.)
I think the selection should be made lower case.  That wouldn't do anything that selecting lower-case would do, but if that's not what the user wanted, he would realise that the "error" is his in not selecting the start of the sentence.  And changing the selection to lower case would give exactly the same outcome as that portion of the sentence would have if the whole sentence had been selected, so there is some consistency there.
I make those two comment, though, on the basis of a user selecting part of *A* sentence.  If one selects several sentences, but only parts of the first and last sentences, doing it this way would make it inconsistent with Capitalise Every Word (which you do raise in Q. 5). 
> 3. What should be done if selection starts in the middle of a word (possibly
> not the first in a sentence)? We could capitalize first character of the
> word (again not good for Shift+F3); or first selected character; or skip the
> sentence. (I'd capitalize first selected character.)
You're still asking about sentence case?  If so, I'd treat this the same as in my answer to question 2.
> 4. What should we do when there's no selection? We could capitalize first
> character of current word (if any; like UPPERCASE at al work); or current
> sentence. (My take is Capitalize current sentence.)
If there is no selection, like other cases, the entire sentence (in this case) should be assumed to be selected.
> 5. What should be done with Capitalize Every Word function, that now also
> expands to whole words, even if only parts are selected? It's not in
> Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> consistently.)
It is in Shift+F3.  I'm undecided on this one.
> 6. Should we only do the change for Word, or for other modules
> (Calc/Impress/etc) too for consistency? (I'd say yes.)
I'd agree yes, although Calc is the only other one I use more than rarely, and I'd rarely use these functions in Calc, so my opinion may not be worth much here.

Your questions are good ones, and I've offered some thoughts, but I probably haven't properly considered all circumstances, so there may be good arguments against what I've said.

(In reply to Ljiljan from comment #41)
> So honouring selection is important. We don't know what user intends to do.
> Selection helps here, not guessing. That was the point of my satire... not
> to offend everyone.
Now THAT was helpful.  I think you've made a good case for that particular circumstance, and it's compatible with the suggestions I offered.  I do think that honouring the selection is important; I just think that there may be special cases where it doesn't apply.  However, honouring the selection should be the starting point.

*** Bug 123977 has been marked as a duplicate of this bug. ***

To UX-Advise to move this forward...

But my take remains that the original implementation applying the SENTENCE_CASE, via ICU transliteration, needs additional control logic. 

Believe we need to handle two cases for applying SENTENCE_CASE in edit engine [1].

1) Case -- an active selection made:

   expand only to the ICU -word boundaries- that hold the selection and apply ICU transliteration. Treat that "temp" string as the sentence--and apply transliteration.  Since the transliteration of the selection likely cross sentence boundaries, would need to break selection into multiple "temp" strings (an opening, middle(s), a closing)--but honor the selections at the word boundaries as the range.

2) Case --  only text cursor focus, no selection made:

   expand only to the ICU -sentence boundaries- that hold the text cursor and apply ICU transliteration.

The current implementation for sentence case always performs the expansion when applying SENTENCE_CASE transliteration, with or without selection--that's the issue. Current implementation probably could/should be retained for a no selection case, but need to provide new code for the with selection handling.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?r=492ea7e0#2665

(In reply to V Stuart Foote from comment #45)

I don't know what ICU means, but if I understand you, this would make any use of cycling with Shift-F3 and no selection unusable.  Suppose you want to capitalise a single word, so place the cursor in that word but don't select it.  Instead of capitalising that word, you could end up applying sentence capitalisation to the entire sentence, an unwanted and unexpected outcome.

(In reply to Philip Rayment from comment #46)
>
> I don't know what ICU means, but if I understand you, this would make any
> use of cycling with Shift-F3 and no selection unusable.  Suppose you want to
> capitalise a single word, so place the cursor in that word but don't select
> it.  Instead of capitalising that word, you could end up applying sentence
> capitalisation to the entire sentence, an unwanted and unexpected outcome.

No! In fact the change in comment 45 of explicitly handling selection state--would restore consistent and expected behavior to the UI and there is only so much protection we can give to users without impacting function.
If premise remains as for bug 116315, that SENTENCE_CASE belongs in the Cycle case list (Title Case, Sentence case, UPPERCASE, lowercase). Usage notes in documentation is sufficient to warn users to make a selection for cycling a single word.

Besides, this is exactly the behavior now. No selection for the other transliterations applies just to the ICU word boundaries at text cursor position,- while SENTENCE_CASE expands from that position to the sentence boundaries so no regression involved.

=-ref-=
ICU -- https://en.wikipedia.org/wiki/International_Components_for_Unicode

(In reply to V Stuart Foote from comment #47)
Should have acknowledged that one other alternative would be to require a selection for any of the Case rotate tranliteration to apply. Force user to make a selection. 

Not very onerous as we select word with double click, sentence with triple click, and paragraph with quad click. With comparable keyboard selection at word bounds.

(In reply to V Stuart Foote from comment #47)

> No! In fact the change in comment 45 of explicitly handling selection
> state--would restore consistent and expected behavior to the UI 

Sorry, I must have misunderstood.  But please explain how this works in more detail.  If you have this sentence:
 "Mary Jones met joe Smith"
and put the cursor in "joe", but didn't select it, and press Shift-F3 to capitalise "joe", but you're at the wrong step in the cycle, then sentence case is applied instead, changing "Jones" to "jones" and "Smith" to "smith".  How does your proposal prevent that?

(In reply to V Stuart Foote from comment #47)
> ... Usage
> notes in documentation is sufficient to warn users to make a selection for
> cycling a single word.

What documentation?  Without trying an extensive search, I couldn't find any documentation on Shift-F3 beyond it being mentioned in the menus.

(In reply to V Stuart Foote from comment #45)
> To UX-Advise to move this forward...

Basically I agree with the selection on/off consideration. But how about to select the whole sentence first when nothing has been selected ("text cursor focus")? And to apply the function as it works today but always to the selection. It has the benefit of being more transparent to the user and simplifies workflow and code.

(In reply to Philip Rayment from comment #49)
>  "Mary Jones met joe Smith"

How the transliteration works is another question to me. I would keep the status quo which means:

(without selection)
TITLE_CASE: Mary Jones Met Joe Smith
SENTENCE_CASE: Mary jones met joe smith
LOWERCASE_UPPERCASE: MARY JONES MET JOE SMITH
UPPERCASE_LOWERCASE: mary jones met joe smith

("Mary Jones met [joe] Smith" - "joe" is selected)
TITLE_CASE: JOE
SENTENCE_CASE: joe
LOWERCASE_UPPERCASE: Joe
UPPERCASE_LOWERCASE: joe

("Mary Jones met [joe Smith]" - "joe Smith" is selected)
TITLE_CASE: Joe Smith
SENTENCE_CASE: Joe smith
LOWERCASE_UPPERCASE: JOE SMITH
UPPERCASE_LOWERCASE: joe smith

Any if-then condition complicates the procedure and makes it hard for users to predict the result.

(In reply to Heiko Tietze from comment #50)
>
> Basically I agree with the selection on/off consideration. But how about to
> select the whole sentence first when nothing has been selected ("text cursor
> focus")? And to apply the function as it works today but always to the
> selection. It has the benefit of being more transparent to the user and
> simplifies workflow and code.
> ...

Might be cleaner to explicitly do nothing unless there is a selection made. Making the expanded selection to sentence boundaries (from text cursor position) would still be too late for the user to avoid an unintended action.

(In reply to Heiko Tietze from comment #50)

> How the transliteration works is another question to me. I would keep the
> status quo which means:
... 
> ("Mary Jones met [joe] Smith" - "joe" is selected)
> TITLE_CASE: JOE
> SENTENCE_CASE: joe
> LOWERCASE_UPPERCASE: Joe
> UPPERCASE_LOWERCASE: joe

Only that's NOT the status quo, if by that you mean what happens now, and if you're using Shift-F3 to cycle (perhaps you weren't referring to that??).  What happens now is:

> ("Mary Jones met [joe] Smith" - "joe" is selected)
> First  keypress: Mary Jones met [Joe] Smith
> Second keypress: Mary jones met [joe] smith (sentence case applied; Jones and Smith decapitalised)
> Third  keypress: Mary jones met [JOE] smith
> Fourth keypress: Mary jones met [joe] smith

I hesitate to suggest this, but one option may be to change the process to be as follows:
> ("Mary Jones met [joe] Smith" - "joe" is selected)
> First  keypress: Mary Jones met [Joe] Smith
> Second keypress: Mary jones met [joe] smith (sentence case applied; Jones and Smith decapitalised)
> Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)
> Fourth keypress: Mary Jones met [joe] Smith

This would be regardless of whether a selection was made or not.  The problem is that if the cycling is also fixed to start from the beginning of the cycle rather than the next step after the previous when a new bit of text is selected, the user might move the cursor elsewhere after the second step and be stuck with the unwanted sentence case.  Although there's always the undo button.

(In reply to V Stuart Foote from comment #51)
> Might be cleaner to explicitly do nothing unless there is a selection made.

That would feel like a regression for people who are used to the function.

(In reply to Philip Rayment from comment #52)
> ... (maybe I missed one cycle)
> I hesitate to suggest this, but one option may be to change the process to
> be as follows:
> ...
> > Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)

Changing text outside the selection contradicts our effort. So I wouldn't touch "smith".

(In reply to Heiko Tietze from comment #53)

> > I hesitate to suggest this, but one option may be to change the process to
> > be as follows:
> > ...
> > > Third  keypress: Mary Jones met [JOE] Smith (sentence case reverted/undone before trying next option)
> 
> Changing text outside the selection contradicts our effort. So I wouldn't
> touch "smith".

The cycling ALREADY changes text outside the selection.  That's the problem (or one of them).  That step I was suggesting merely /reverts/ that change when sentence case is not required.  (And it wasn't just Smith; it was also Jones.)

(In reply to Philip Rayment from comment #54)
> The cycling ALREADY changes text outside the selection.  That's the problem...

Seems we agree on the required change. Cycle case should work on the selection and if there is none on the full sentence (as today). The consideration of automatically selection or doing nothing was misleading and might confuse users.

(In reply to Heiko Tietze from comment #55)
> 
> Seems we agree on the required change. Cycle case should work on the
> selection and if there is none on the full sentence (as today).

OK, we should proceed--apply SENTENCE_CASE with a bimodal behavior [ selection | no selection ].

But, Mike K's list of questions from comment 34 need a resolution. 

Also there is Justin L's work on bug 63529 and his abandoned https://gerrit.libreoffice.org/#/c/33581/ which tweaked word boundaries and proposed some control over the transliteration sequence depending on current state. 

Should we address that from UX perspective--or let it be, and just be satisfied here  with consistent "bimodal" selection handling of the fixed transliteration sequence for caserotate.cxx, i.e.:

TITLE_CASE -> SENTENCE_CASE -> LOWERCASE_UPPERCASE -> UPPERCASE_LOWERCASE;

(In reply to Mike Kaganski from comment #34)
> 1. What should be done when a sentence start is selected, but not to the
> sentence end? (I'm pretty confident the sentence start here should be
> capitalized.)

Yes, with selection of start of sentence--but not the whole run should honor the selection--capitalize first character, the rest of the selection to lower case per sentence case).

> 2. What should be done if a sentence end is selected, but not from start?
> (This one IMO is not that straightforward: we can capitalize the first
> selected character, or we may skip the sentence; my take would be capitalize
> first selected character.)

Yes, with selection made--honor the selection. Capitalize the first selected character, remainder of selection to lower case.

> 3. What should be done if selection starts in the middle of a word (possibly
> not the first in a sentence)? We could capitalize first character of the
> word (again not good for Shift+F3); or first selected character; or skip the
> sentence. (I'd capitalize first selected character.)

Yes, with selection made--pass exactly that string for transliteration--and then only the TITLE_CASE would need to expand to its word bound.

> 4. What should we do when there's no selection? We could capitalize first
> character of current word (if any; like UPPERCASE at al work); or current
> sentence. (My take is Capitalize current sentence.)

With no selection, i.e. text cursor only, this remains the rub! But, if no selection--should probably not apply to the whole sentence, applying just to the word at the text cursor position would "protect" users from clobbering things. Sentence case would then match the other transliterations.

> 5. What should be done with Capitalize Every Word function, that now also
> expands to whole words, even if only parts are selected? It's not in
> Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> consistently.)

Hmm, looks like the TITLE_CASE transliteration has always been in the caserotate.cxx -- obviously it has to apply to the Word bounds, current word for no selection--and to all words of a selection (including the opening word).

> 6. Should we only do the change for Word, or for other modules
> (Calc/Impress/etc) too for consistency? (I'd say yes.)

Needs consistency across _ALL_ modules

As a side bar to handling this--added a request for an UNO action to "Select Sentence" as bug 124552, to more precisely select sentence via a keyboard shortcut rather than a mouse cursor drag.

(In reply to V Stuart Foote from comment #57)
> (In reply to Mike Kaganski from comment #34)
> ....
> Yes, with selection made--honor the selection.

Fully agree.

> > 5. What should be done with Capitalize Every Word function, that now also
> > expands to whole words, even if only parts are selected? It's not in
> > Shift+F3 IIUC, but it would become inconsistent. (I'd say change it
> > consistently.)
> 
> Hmm, looks like the TITLE_CASE transliteration has always been in the
> caserotate.cxx -- obviously it has to apply to the Word bounds, current word
> for no selection--and to all words of a selection (including the opening
> word).

We could introduce an (advanced) option "[ ] Expand selection to word boundaries for transliteration" that changes the selection first. Looking at Justin's patch note 

| enhance Shift-F3 rotating between UPPER, lower, Title cases. 
| - allow cursor at the beginning of the word
| - allow cursor at the end of the word
| - allow cursor in whitespace before a word 
| - rotate based on current status, not on a blind counter

supports the idea of simplification.

*** Bug 124760 has been marked as a duplicate of this bug. ***

Most of the duplicates here are complaints that Sentence case was added to the Shift-F3 sequence in LO 6.1 

author	heiko tietze 2018-03-26 14:58:23 +0200
commit 84f8e28d092676aad830a9fbae8145a57c6301bc
bug 116315 - Cycle Case including Sentence case
Sentence case added at position #2 in the sequence

(In reply to Justin L from comment #60)
> Most of the duplicates here are complaints that Sentence case was added to
> the Shift-F3 sequence in LO 6.1 
> 
> author	heiko tietze 2018-03-26 14:58:23 +0200
> commit 84f8e28d092676aad830a9fbae8145a57c6301bc
> bug 116315 - Cycle Case including Sentence case
> Sentence case added at position #2 in the sequence

Well sure--it functioned as intended when only applied via menu action (now at Format -> Text -> Sentence case). As Mike reported in OP, it was annoying then that the transliteration did not honor a selection if made.

Addition to the Cycle Case sequence for bug 116315 brought it to a head.

Fundamentally the same issue--it does not honor Selection and expands to affect entire sentence run. 

And, sidebar have a sneaking feeling that it is not using the ICU libs to delimit sentence runs at correctly set bounds, kind expect CTL and CJK scripts are not well handled but I've not dug deeply at them.

In 
my Version: 6.2.4.2
Build-ID: 1:6.2.4-0ubuntu0.18.04.1~lo1

it is even more odd:

* put the cursor in one word - hit Shift-F3: case of that word cycles
* put the cursor in another word - hit Shift-F3: case of that word cycles, BUT AS WELL THE CASE OF THE WORD TOUCHED BEFORE

Please repair that function, it's really important!

*** Bug 127432 has been marked as a duplicate of this bug. ***

Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20

*** Bug 129144 has been marked as a duplicate of this bug. ***

*** Bug 130331 has been marked as a duplicate of this bug. ***

*** Bug 130749 has been marked as a duplicate of this bug. ***

*** Bug 134123 has been marked as a duplicate of this bug. ***

Confirmed with:

LOdev 7.0.0.0.beta1
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
Manjaro Linux
CPU threads: 4; Kernel 5.6
UI render default; VCL: kf5
Locale: pt-BR (en_US.UTF-8); UI: en-US

Fwiw and not wishing to add to the heat generated above, as a simple user of LibreOffice this is not expected behaviour: if I select a section of text and conduct an operation, I expect it to be restricted to the selection.  Please may I add my immense gratitude to all those who give their time and effort to make this such a superb piece of software.  Thank you.

*** Bug 138346 has been marked as a duplicate of this bug. ***

*** Bug 138611 has been marked as a duplicate of this bug. ***

*** Bug 133427 has been marked as a duplicate of this bug. ***

Fwiw and not wishing to add to the heat generated above, as a simple user of LibreOffice this is not expected behaviour: if I select a section of text and conduct an operation, I expect it to be restricted to the selection.  Please may I add my immense gratitude to all those who give their time and effort to make this such a superb piece of software.  Thank you.

In version 7.2, the Cycle Case command is still largely unusable for the use cases that are important to me.

What can we, as users, do to help the developers fix it sooner?

- Is more user input needed for creating a new specification? Would it be helpful to provide some more use cases to help decide on the best approach that won't cause regressions for other users?

- Are the developers too few and/or too busy with more important stuff to tackle the issue for the time being? Can we agree on a quick, minimal temporary fix (like reverting the inclusion of Sentence Case in Cycle Case) and postpone any functionally better but time consuming refactor (like modifying Sentence Case or providing a separate Initial capital command, analogous to lowercase / UPPERCASE / Title Case, to replace Sentence Case in Cycle Case) for a better time?

- Is the issue currently considered unimportant? If yes, how can we verify objectively that the people complaining from it are representative for a larger group of users and not a random vocal minority as suggested several comments above?

***

As the commenters above, I would like to thank the developers for their tireless work on a wonderful project!

(In reply to Mihail Balabanov from comment #76)
> What can we, as users, do to help the developers fix it sooner?

Find a volunteer or get professional support. Changing the selection is not a simple task and at least beyond my skills.

For the time being, I published my workaround solution as an extension. It is a LibreOffice Basic macro for Cycle Case which honors the selection, autoselects only a single word when there is no selection, uses the current case of the selected text for a starting point instead of a counter, and can cycle the case of word the user just typed (including when there is already a space between it and the cursor).

https://extensions.libreoffice.org/en/extensions/show/4036

*** Bug 143296 has been marked as a duplicate of this bug. ***

Created attachment 173648 [details]
concrete test cases

Since the discussion on this bug has been such a long winding road, I have attempted to boil down what I interpret as the consensus desired behavior into a set of concrete test cases (see attached). This incorporates the decisions in Comment 57.

As you can see in the SENTENCE_CASE tests, 7.2.0.1 will not only change the case of the first sentence (where the cursor or selection are) but also the P in the second sentence (where IMHO it shouldn't be changing anything at all). This may be another instance of what was observed in Comment 62.

In the case that there is no selection and the user presses Shift+F3, I personally like the idea of either doing nothing (as raised in Comment 51) or expanding the selection to show the specific characters that were considered in the operation, as raised in Comment 50 and Comment 58. The way it is now, it seems too likely that an action like SENTANCE_CASE would alter characters in my sentance that I wouldn't notice; for example, if the cursor is near the end of a long sentance, and I am looking at the cursor, but the command has altered the beginning of the sentance, where I wasn't watching. But I leave that idea out of the test cases for this bug as I don't want to expand the scope of this bug any further and that seems like an enhancement request suitable for another BZ item.

*** Bug 143584 has been marked as a duplicate of this bug. ***

Loss of selection is confusing folks into thinking bug 116315 is at fault.

Rather the issue is mishandling of target for the transliteration sequences. Addressing target for transliteration, both with and without a selection being made. Additional control logic is needed... 

@Michael W., great that you are poking at this, how are things progressing? Concur with your "concrete test casses" of attachment 173648 [details] implementing comment 51. That is with no selection, just text cursor position, target is only the current word bounds holding the text cursor. No expansion. That would be consistent and workable, especially as a triple mouse click now will select a sentence and quadruple click full paragraph.

And may need attention to handling at the ICU word bounds for sentence ends and punctuation.

(In reply to Michael Warner from comment #81)
> As you can see in the SENTENCE_CASE tests, 7.2.0.1 will not only change the
> case of the first sentence (where the cursor or selection are) but also the
> P in the second sentence (where IMHO it shouldn't be changing anything at
> all). This may be another instance of what was observed in Comment 62.

ICU does not detect the sentence break in this case. If I capitalize the T in Time, it works as expected. We could track this in another BZ item, but it's not our bug. I will modify the test cases for this bug to avoid that one.  


(In reply to V Stuart Foote from comment #83)
> @Michael W., great that you are poking at this, how are things progressing?

I have some local code modifications made but work is not complete yet. I know it's a slow pace but I am only a contributor.

> Concur with your "concrete test casses" of attachment 173648 [details]
> implementing comment 51. That is with no selection, just text cursor
> position, target is only the current word bounds holding the text cursor. No
> expansion. That would be consistent and workable, especially as a triple
> mouse click now will select a sentence and quadruple click full paragraph.

Actually what I put in test 1a is that it capitalizes the first letter of the current word, and down-cases the letters to the end of the sentence (you can see this happen on the S in Smith). But the downside to this approach is that letters that are down-cased when we apply the sentence case are not restored on the next press of Shift-F3, so from the user's perspective there is still an unintended side-effect there. 

Thinking about it some more, I agree with you that only changing the case of the current word when there is no selection is the best choice. It's consistent with the other actions. I will update Test 1a to reflect this.

Created attachment 174583 [details]
Changed per Comment 84

Now there's an inconsistency between tests 3a and 3b, in that the N in Jones is capitalized for sentence case, but remains lower for title case.

(In reply to Michael Warner from comment #84)
>This may be another instance of what was observed in Comment 62.
> 
> ICU does not detect the sentence break in this case. If I capitalize the T
> in Time, it works as expected. We could track this in another BZ item, but
> it's not our bug. I will modify the test cases for this bug to avoid that
> one.  
> 

No, believe we control the logic for the start/end of a sentence--pretty sure it is with ICU libs [1], but I've not followed it fully through the edit shell. But see here to start where we seem to use a DICTIONARY_WORD ICU break iterator to control expanding bounds for the sentence:

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit4.cxx?a=true&r=492ea7e0&h=2785#2785

And, the SENTENCE_BREAK ICU iterator is available, but looks bit dated (and not to be used with the transliteration) as defined here:

https://opengrok.libreoffice.org/xref/core/i18npool/source/breakiterator/data/sent.txt?r=2b383d19

But if the no-selection case is only going to apply to the word with text cursor position--the ICU sentence bounding would not be helpful.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/i18npool/source/breakiterator/breakiterator_unicode.cxx

(In reply to V Stuart Foote from comment #86)

The ICU methods for "Break Rules" are described here:

https://unicode-org.github.io/icu/userguide/boundaryanalysis/break-rules.html

I get a sense now for why the DICTIONARY_WORD approach--it is needed for Thai, Lao, Khmer, Burmese, and Japanese--and with CLDR details is more precise for determining sentence breaks in general.

Again--key here is difference between transliteration done with a selection (which must honor the *initial* selection exactly as the transliteration cycles) and transliteration done without a selection.  

The without selection transliteration should be bounded on the ICU *word* holding the text cursor.

And if text cursor is on a space or punctuation--IMHO it is probably best to not perform a transliteration for that case.

Created attachment 174593 [details]
Updated Test Set 4

Fixed some errors in Test Set 4.

(In reply to Michael Warner from comment #89)
> Created attachment 174593 [details]
> Updated Test Set 4
> 
> Fixed some errors in Test Set 4.

That looks good! Any issue with no-selection and text cursor is not within a word? I.e. on a space or punctuation...

@Michael --if your local patches are producting those results perhaps push up to gerrit for additional review. Can wrap this up...

(In reply to V Stuart Foote from comment #90)
> (In reply to Michael Warner from comment #89)
> > Created attachment 174593 [details]
> > Updated Test Set 4
> > 
> > Fixed some errors in Test Set 4.
> 
> That looks good! Any issue with no-selection and text cursor is not within a
> word? I.e. on a space or punctuation...

I will add more test sets for this.

> @Michael --if your local patches are producting those results perhaps push
> up to gerrit for additional review. Can wrap this up...

This document I maintain by hand to ensure we have concurrence on what the behavior should be. My local build still fails a couple of test cases; I am continuing to work on it.

*** Bug 63889 has been marked as a duplicate of this bug. ***

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

Created attachment 175302 [details]
Test Set rev 5

Based on comments in code review, I changed the Proposed New State of Test #1a to revert back to the old behavior of operating on the entire current sentence when there is no active selection.

*** Bug 144856 has been marked as a duplicate of this bug. ***

Michael Warner committed a patch related to this issue.
It has been pushed to "master":

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

tdf#49033 Honor Selection When Applying Sentence Case Format

It will be available in 7.3.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.

Seems resolved IMHO.

Testing trunk against 7.4 with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 7e5af164b7d293dd410710bed411e1ca64bbecf7
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

When a selection is made, the <Shift>+F3 Cycle Case honors the selection.

With no selection--i.e. just text cursor focus--cycle case still will expand to ICU sentence bounds for setting sentence case, while other transliterations apply just at the word bound without selection.

Seems the correct behavior.

(In reply to V Stuart Foote from comment #97)

> Seems the correct behavior.

Likewise if using the Format -> Text -> 'Sentence case' toggle directly--it now honors selection when made, or transliterates to ICU sentence bounds without. Issue of OP is also resolved.

@Mike, do you agree?

(In reply to V Stuart Foote from comment #97)

> With no selection--i.e. just text cursor focus--cycle case still will expand
> to ICU sentence bounds for setting sentence case, while other
> transliterations apply just at the word bound without selection.
> 
> Seems the correct behavior.

If this is the desired behavior, the command should not be called Cycle Case because it is not cyclic. The user cannot return to the initial state if one of the steps changes more text than the others. For me this behavior seems inconsistent and counterintuitive but if most users actually prefer it (are we sure that this is the case?), we should rename the command.

I think the better approach in terms of user experience is to just skip the Sentence Case step when there is no selection (because we should act on a single word for consistency but for a single word Sentence Case is the same as Title Case). We still have the separate Sentence Case command that can be used without selection and does exactly what the user expects, acting on the entire sentence.

On a side note, in my Cycle Case plugin, I check the state of the text before applying the next step and take care to skip redundant steps, for example a single-letter selection will just toggle between Lowercase and Uppercase, skipping Initial Capital and Title Case because for such a selection they are the same as Uppercase. (Calling it Initial Capital instead of Sentence Case in the context of Cycle Case helps to change perspective – suddenly, it no more appears mandatory to act on an entire sentence.)

(In reply to Mihail Balabanov from comment #99)

Issue of OP is resolved. This is "fixed". With selection the Cycle case (or Format -> Text -> Sentence case_ honors the selection when made. 

What happens without selection is as implemented--expand from text cursor position for non-selection to sentence bounds when applying Sentence case. <Ctrl>+Z reverts if undesired.

Dropping the Sentence case from the 4 'Cycle case' modes when no selection is made would require a rewrite with additional control logic for the cycle case--that was not done here, and really doesn't seem necessary. 

Michael did a nice job getting the issue resolved.

But patches for the logic rewrite are of course welcome...

(In reply to Mihail Balabanov from comment #99)
> (In reply to V Stuart Foote from comment #97)
> 
> > With no selection--i.e. just text cursor focus--cycle case still will expand
> > to ICU sentence bounds for setting sentence case, while other
> > transliterations apply just at the word bound without selection.
> > 
> > Seems the correct behavior.
> 
> If this is the desired behavior, the command should not be called Cycle Case
> because it is not cyclic. The user cannot return to the initial state if one
> of the steps changes more text than the others. For me this behavior seems
> inconsistent and counterintuitive but if most users actually prefer it (are
> we sure that this is the case?), we should rename the command.

I direct your attention to Bug 144853 for further discussion of this topic.

*** Bug 146234 has been marked as a duplicate of this bug. ***

*** Bug 156429 has been marked as a duplicate of this bug. ***