Description: Probably blocked by #141773. Steps to Reproduce: 1. Open Writer 2. Go to Tools > AutoCorrect > AutoCorrect Options Actual Results: You will see your current language being selected, and a long list of symbol auto-replacements, starting with --> → :_-: ₋ :_(: ₍ Expected Results: Most of these replacements aren't actually language specific, and they should instead be defined in [All], for easier maintainability, more flexibility in the options, and availability in the [None] language context, see below: Reproducible: Always User Profile Reset: No Additional Info: ---------------------------- 1. EASIER MAINTAINABILITY ---------------------------- I would expect, that keeping the list of symbol replacements consistent across languages already uses some "all languages" table in the built process. Such an option does not exist for the end user though, and the end user has to manually add new symbols to all languages they use. ----------------- 2. FLEXIBILITY ----------------- I usually prefer to disable auto-replacement options, but I would prefer to retain the symbol auto-replacements. Currently I simply delete auto-replacements that get in the way, but it isn't ideal and can be a nuisance whenever using a new setup. Separating such non-language replacements into the [All] category, or maybe a newly created [Symbols] category, would allow making "disable word replacement rules" and "disable symbol replacement rules" separate options. --------------------------------- 3. THE [None] LANGUAGE CONTEXT --------------------------------- I came across this issue when using the [None] language option. For instance, I wanted to write something like Entry1 → Entry2 → Entry3 to describe a dropdown menu sequence, or order of actions, where the words are things like function names, that do not constitute valid dictionary words (e.g. due to the use of CamelCase). Another use case would be creating inline equations in Impress, where the equation editor cannot be used for the purpose. Writing something like f(t) = sin(i:omega:t), producing f(t) = sin(iωt) could be quite useful, but as written will have iωt flagged by the spell checker. Combined with the need to set a distinct font, it makes sense to define a character style, that - switches the font to a serif font in italics - sets language to [None] But this then hampers the workflow, as setting the language to [None] can be done only after using the auto-replace entries.
I beg to differ: [None] means exactly that, _no language tool processing at all_. [All] should be processed in, well, all languages except [None].
Since it is an enhancement request let's ask design-team
Would agree with populating a listing [ALL] for common use, where a majority of current replacements across all locales/supported langs should be consolidated and delivered. Then the delivered locale/lang specific autocorrection listings could be reduced. The [All] listing of corrections is present, but empty. Requiring user action to populate. Don't see a need to invest in a [None]. @Lásló, how do you see this?
These are defined in extras/source/autocorr/*/DocumentList.xml for >ls af-ZA da en-AU es ga-IE is lb-LU nl-BE pt-PT sl sr-Latn-RS th zh-CN bg de en-GB fa hr it lt pl ro sr-CS sr-ME tr zh-TW ca dsb en-US fi hsb ja mn pt ru sr-Latn-CS sr-RS vi cs el en-ZA fr hu ko nl pt-BR sk sr-Latn-ME sv vro Meaning Hebrew, for example, has no replacement for -->. But it feels to me as if this is controlled by the local community since we have no configuration for [All], whether it is actually none or any. My take is WF.
(In reply to V Stuart Foote from comment #3) > Would agree with populating a listing [ALL] for common use, where a majority > of current replacements across all locales/supported langs should be > consolidated and delivered. > > Then the delivered locale/lang specific autocorrection listings could be > reduced. As a user, another advantage would be making customization easier. For instance, I write documents in German and English and if I want to customize language-independent auto-replacements like :alpha:, I need to manually do so for each language that I use. > The [All] listing of corrections is present, but empty. Requiring user > action to populate. > > Don't see a need to invest in a [None]. Please keep in mind, that currently [All] and [None] are somehow conflated, with replacement rules defined for [All] being applied to text with language [None], but to no other language. (In reply to Eike Rathke from comment #1) > I beg to differ: > [None] means exactly that, _no language tool processing at all_. > > [All] should be processed in, well, all languages except [None]. Currently, my use-case can be made to work with the workaround of 1. Editing the auto-corrections for English (USA) and [All] to ensure that ~/.config/libreoffice/4/user/autocorr/acor_en-US.dat ~/.config/libreoffice/4/user/autocorr/acor_und.dat both exists. 2. Close LibreOffice. 3. Replace acor_und.dat by a copy of acor_en-US.dat. This workaround works, because currently the replacement rules for [All] are actually used for [None] text. If in the future [None] text uses no auto-correction rules at all, the workaround will not work anymore.
(In reply to V Stuart Foote from comment #3) > Would agree with populating a listing [ALL] for common use, where a majority > of current replacements across all locales/supported langs should be > consolidated and delivered. > > Then the delivered locale/lang specific autocorrection listings could be > reduced. > > The [All] listing of corrections is present, but empty. Requiring user > action to populate. > > Don't see a need to invest in a [None]. > > @Lásló, how do you see this? [All] would be useful, but only for a dozen of the replacements, e.g. the general typographical symbols mentioned before: :-->:, :x: -> ×, Unicode subscript/superscript letters :^2: -> ². But Emojis, moreover names of greek letters are localized, e.g. :alpha: and :omega: are :alfa: and :ómega: in Hungarian. But moving these items to [All], we can lose something: to educate the users better about the nice possibilities of LibreOffice. Possible better fix for the possible UX problem: adding a button to show only the items added by the user optionally, or move all the :colon: replacement items in a different pane in the dialog window. (By the way, using Unicode superscript/subscript letters would be unnecessary, if Calc/Impress support superscript/subscript better, or if optical sizes were supported by Writer superscript/subscript automatically, like font variants of Source Serif: https://blog.adobe.com/en/publish/2021/03/04/source-serif-gets-optical-sizes).
We discussed the topic in the design meeting. Adding some replacement to the [ALL] category makes it effective for paragraphs with language = None or empty replacement lists but not en_US, for example. If we distinguish between [<lang>] and [All] users wont see either the one or the other. And two lists adds prioritization questions meaning what happens when the same term is defined in both lists. For example [All] --> = -> vs. [Hebrew] --> = <-. So the recommendation is to remove [All] from the dropdown menu (at this tab), and to make [None] actually none. I suggest to change the summary, if this is accepted.