[Libreoffice-ux-advise] [Bug 139397] Rework auto-correction mechanisms for better UX

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=139397

--- Comment #6 from Telesto <telesto at surfxs.nl> ---
(In reply to V Stuart Foote from comment #5)
> Presently, the entire list is subject to user customization--a user can
> delete any LO provided default entries they find inappropriate, and may add
> any mnemonic for string replacements they find useful.

First off noting that editing the replacement list currently broken (in various
ways, depending on language): bug 96787, bug 119177, bug 139396 
But well those are bugs will be fixed someday. So not a reference

Remains what bug 139377 expressed related to daß and dass. Any replacement lis
taking sides.. and is installed by default. Which for my taste is a kind of
'problematic'. In the sense of LibreOffice is answering linguistic questions.
By saying 'dass' being proper (in line with reform of 1996). Which isn't forced
upon the user. 
Wikipedia writes that there plenty of standards for different papers (but no
clue if this still being valid; kind of dated wiki page)

So the whole replacement thing bit hairy to me.  

No clear if there are clear rules for dictionary maintainers. If something
should be added to replacement list/when not etc. The list appears to be kind
of subjective. And it's enabled by default. 

Not much against smiley's. Which I even consider being separated from 'normal'
replacements (but possibly my preference + and obviously development effort).
So not sure how realistic this is.

And of course the opposite. The usefulness in general. So people expecting this
to happen.

I personally dislike auto-replacements (without any feedback). Auto-correct
correcting wrongly is pretty infuriating. And if you don't realize its caused
by auto-correct.. And auto-correct is kind of buried. So I personally don't
associate auto-correct with replacement list. I might even read Auto-correct as
being about the spell-checker.

So yes, I admit the possibility of editing partly solves the issue. But you
need to be aware.. I no, I didn't know at first, nor did the reporter in bug
139377.

It also shows how infuriating this can be. Exactly the same topic at play with
'markdown' [sorry keep bring this up]. Trying to type a directory path is kind
of a thing. Or wanting to accentuate something with *HELLO* (without being
bold)
Which again a hidden feature (or annoyance, depending on perspective).

And the speculating about how large group are seeing this as (feature) or
(annoyance) is not obvious. And kind of dislike the way it forced up on
someone.

The topic of 'needing' development effort. Certainly not unique. So closing
because it needs development effort as isn't real argument for some 'change'.
If we can come up with something.

Development effort means to me.. well priority.. so lots of effort with present
long list of other more pressing issue.. ends up with LOW ENHANCEMENT. Still OK
with that :P

I personally perceive it as recognition that sometime could be improved. Even
if this factual means no change in the upcoming 5, maybe 10 years :-). But it's
taken seriously but not seen as most pressing matter. 

It might be bit more sentimental compared to certain pragmatism. The pragmatic
will reason: this won't be fixed anytime soon. Not extremely pressing, and we
enough to do already. So let it vanish of the radar (and not 'bloating' the bug
tracker any further) 

While I would argue; it has a tremendous size already; are we picky on small
selection of bugs.. :-). And really wrong to say, well this could be improved
with some kind of direction. 

If there is no realistic options doing it differently, closing is obviously the
decision to make.

[Sorry for the long read]. I think I ruined this report already, making it to
long.

-- 
You are receiving this mail because:
You are on the CC list for the bug.