LO has Default Language settings, accessing via Tools | Options | Language Settings | Languages. These affect the languages for each language group in the Default Paragraph Style's Character Style aspect. However, the Default PS is a feature of the document, and the LO default is a non-document setting. Therefore, once a document has been created, the language choices it has been imbued with for the Default PS must no longer be affected by the app defaults. Yet - they are: If we change the default in Tools | Options | Language Settings | Languages, the Default PS changes as well.
The current help text is: Under Default languages for documents, select the document language for all newly created documents. If you mark For the current document only, your choice will only apply to the current document. Close the dialog with OK. I think, that the help text is misleading and should be improved. The setting _always_ affects the current active document. When the 'For current document only' option is _not_ checked, then the change is stored in addition in the user profile in the registrymodifications.xcu file. And the info there is used for new documents. I have changed Component to Documentation.
It is an UX problem in addition. Perhaps the checkbox meaning should be reversed and the label changed to something like "In addition, store setting in user profile and thus be used for new documents." Or add a new functionality, that the settings can be written to user profile only, and have two check boxes, one "Apply changes to current document" and the other "Store changes in user profile".
(In reply to Regina Henschel from comment #1) The problem is not merely the help text. It is inappropriate for an LO app setting, changed while a document is being edited, to result in changes to the document. Nothing in Tools | Options should set properties of an existing document. So, I claim that: * "For Documents" should be replaced with "For new documents" * "For current document only" must simply be removed. * The help text should be corrected. ... in addition to the basic requested fix, which is for the settings there not to be applied to open documents nor to existing documents as they are opened; only on creation.
Not clear there is an issue here. Behavior is reasonable, but incorrectly documented -- that change is valid. As to any need to change the legacy behavior--that is not proved and frankly is not necessary. Setting back to UNCONFIRMED as there is NO agreement to change the behavior of default language affecting PS of current document.
(In reply to V Stuart Foote from comment #4) > Not clear there is an issue here. Behavior is reasonable I explained why it is unreasonable: An application settings dialog has controls which effect changes in the currently document. This is a faux pas.
(In reply to Eyal Rozenberg from comment #5) > (In reply to V Stuart Foote from comment #4) > > Not clear there is an issue here. Behavior is reasonable > > I explained why it is unreasonable: An application settings dialog has > controls which effect changes in the currently document. This is a faux pas. The Default Languages part is not the only one, which affects the current document. See bug 144814 for a discussion about such problems. And for language related problems see bug 104318 and a collection of problems in bug 112139. I still think, that we should at least write the help text so, that the user is clear about the impacts of these settings. That would be for LO 7.4 and 7.5. Any change in functionality will likely not be ready in 7.5.
(In reply to Eyal Rozenberg from comment #3) > It is inappropriate for an LO app > setting, changed while a document is being edited, to result in changes to > the document. Nothing in Tools | Options should set properties of an > existing document. That's not true. Many settings do and must affect the current (or even all) open document(s). For example the default locale that immediately switches display formats of all open Calc documents if a cell is attributed with a Default locale's number format and the corresponding input number/date recognition. Or view options and calculation options.
(In reply to Eike Rathke from comment #7) > (In reply to Eyal Rozenberg from comment #3) > > It is inappropriate for an LO app > > setting, changed while a document is being edited, to result in changes to > > the document. Nothing in Tools | Options should set properties of an > > existing document. > That's not true. Many settings do and must affect the current (or even all) > open document(s). I believe you misread my last comment. I didn't say they _don't_ affect the current document, I said that they _shouldn't_. Note also Regina's comment above.
I did not misread. I said many *must* affect the current document.
(In reply to Eike Rathke from comment #7) > I did not misread. I said many *must* affect the current document. Well, 1. Why do you believe they must? 2. Perhaps you should voice this opinion (also) on bug 144814.
(In reply to Regina Henschel from comment #6) > I still think, that we should at least write the help text so, that the user > is clear about the impacts of these settings. That would be for LO 7.4 and > 7.5. Any change in functionality will likely not be ready in 7.5. I agree - and have filed bug 152055 about this.
Suggest to handle these questions with bug 103036. There is a large number of tickets around language settings that makes it very hard to handle the topic.
(In reply to Heiko Tietze from comment #12) > Suggest to handle these questions with bug 103036. Well, they're certainly related. But - to be honest, I feel the mess we are facing regarding (default) language setting is more than about just the UI, and I don't believe 103036, which is about creating a dialog, is "the" issue, which this needs to be a duplicate of. I mean, if you ask Regina, for example, she tells you (bug 151906 comment #12) that there is no document language; when Stuart says that it does exist (bug 151906 comment #13). We see the terms "document language", "default language" and "language / for all text" in different places in the UI. The help pages (e.g. /help/en-US/text/shared/optionen/01140000.html ) don't clarify whether there's a single default language or one for each language group. Then there's the fact that languages are mostly set through styles (as Regina says in bug 151215 comment #6), a fact which, if thus perceived by a user, would make them believe that setting the default language or default language-of-a-language-group, means setting an aspect of some default style. So maybe a meta bug about getting all of this stuff in order? Or maybe start from writing some document, or blog post, clearing things up? Or an ESC discussion? I don't know.
(In reply to Eike Rathke from comment #7) > (In reply to Eyal Rozenberg from comment #3) > > It is inappropriate for an LO app > > setting, changed while a document is being edited, to result in changes to > > the document. Nothing in Tools | Options should set properties of an > > existing document. > That's not true. Many settings do and must affect the current (or even all) > open document(s). For example the default locale that immediately switches > display formats of all open Calc documents if a cell is attributed with a > Default locale's number format and the corresponding input number/date > recognition. Or view options and calculation options. This is a problem of wording/terminology IMO. Let me try to explain the differences as I see, and let Eyal and Eike correct me if I misunderstood. What Eyal claims is: Options dialog should not contain/set *properties* of anything in the currently open document (model). What Eike claims is: it's OK for Options dialog to contain options that may affect currently open document behavior (e.g., display of something, or even calculation results). When talking about default locale, Eike talks about an application-wide setting that defines for a *local application instance* what to do when some property is *not specified in the document*. This is not a property of the document, and as such, it is OK to both have such setting in Options (or other application-scope dialogs), *and* affect currently open documents. This does not contradict the Eyal's idea. I support a vision that each and every option that is be stored in the document, should be removed from the Options dialog; and wherever it gets finally landed, it may get a "make default" button, to allow *also* to store this piece of settings into the profile as a default value for newly created documents.
(In reply to Mike Kaganski from comment #14) Mike summarized my position correctly. > I support a vision that each and every option that is be stored in > the document, should be removed from the Options dialog; Agree so far. > and wherever it gets finally landed, it may get a "make default" > button, to allow *also* to store this piece of settings into the > profile as a default value for newly created documents. I'm not against this in principle, but: * If you did this everywhere it is possible, you would need to allow every feature of, say, the default page style and default paragraph style to be "made default". That's a lot of buttons... * You may also/instead want to consider the 'mirror' approach to your suggestion, i.e. having the LO options dialog have buttons for "adopt settings in current document as the default for new documents". * Wouldn't some of these "default value" settings actually belong in the template file rather than the app option?
(In reply to Eyal Rozenberg from comment #15) > > and wherever it gets finally landed, it may get a "make default" > > button, to allow *also* to store this piece of settings into the > > profile as a default value for newly created documents. > > I'm not against this in principle, but: > > * If you did this everywhere it is possible, you would need to allow every > feature of, say, the default page style and default paragraph style to be > "made default". That's a lot of buttons... > * You may also/instead want to consider the 'mirror' approach to your > suggestion, i.e. having the LO options dialog have buttons for "adopt > settings in current document as the default for new documents". > * Wouldn't some of these "default value" settings actually belong in the > template file rather than the app option? Every default may (and best does) apply to templates. But yet: 1. There are these existing controls in Options, that allow to set the non-template defaults; and if they are needed at all, we should decide where they are; 2. There are cases where even templates don't suffice - like Calc column default width/height, something hardcoded, and used e.g. when you delete some rows/columns, and Calc appends the new stuff, and there are people who consider impossibility to customize it to be a bad thing; 3. It is good to not multiply places where you configure one thing. E.g., when you think about font, you go to Format->Character; and having font settings *also* in other place (in Options just for defaults) is a bad UX; 4. Having a single "apply this document settings as global defaults" would be inconvenient, given how many things may come from the document, which user is even unaware of (does user know e.g. if the printer setting would be stored, and then cause delays when the network printer is turned off?).
(In reply to Mike Kaganski from comment #16) > Every default may (and best does) apply to templates. But yet: > 1. There are these existing controls in Options, that allow to set the > non-template defaults; and if they are needed at all, we should decide where > they are; So, case-by-case basis. > 2. There are cases where even templates don't suffice - like Calc column > default width/height, something hardcoded, and used e.g. when you delete > some rows/columns, and Calc appends the new stuff, and there are people who > consider impossibility to customize it to be a bad thing; Indeed, that's a good example of something I wouldn't put in a template (although, theoretically, you probably could), and would keep in the LO options dialog. > 3. It is good to not multiply places where you configure one thing. E.g., > when you think about font, you go to Format->Character; and having font > settings *also* in other place (in Options just for defaults) is a bad UX; Agree in most cases, but not always. There is also something to be said for dividing the UI by semantic categories. Anyway, I have no strong opinion. > 4. Having a single "apply this document settings as global defaults" would > be inconvenient, given how many things may come from the document, which > user is even unaware of (does user know e.g. if the printer setting would be > stored, and then cause delays when the network printer is turned off?). This might also be a matter of balance between extremes: A single button for all settings is inconvenient, but so are a hundred buttons for a hundred settings. Or maybe even a dialog for selecting which features to adopt as defaults? Just thinking out loud.