[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #69 from daniel.scha...@gmail.com --- (In reply to Michael Bauer from comment #68) > Can someone explain to me how in this scenario I force LO to > a) use a language that I cannot currently set (because it's not offering it > to me) > b) use a language I haven't recently used because LO never offers it > c) doesn't suggest because it thinks Gaelic is Tibetan? "More..." should get you what you crave. The lists "For Paragraph" and "For All Languages" currently doesn't show recently used languages. The list "For Selection" does offer recently used languages ... sometimes (see bug 161344). Although, "More..." should open a dedicated language selection dialogue. Right now, "For Selection/Paragraph" opens the "Character" dialogue, while "For All Text" opens the LO/Writer "Options" dialogue. If "More..." would open a dedicated language selection list directly, we could skip/scrap "recently used languages" too. Currently, we have to click "More...", search for "Language", click on the language selection to expand the language list, and then scroll to the language of choice in a list filled with languages that aren't even available/installed ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #68 from Michael Bauer --- >= >Language(s) used in current document/selection/paragraph: >English (UK) >☑ French (France) >More ... >- >Recently used languages: >Some Language >Some other language >Yet another language >- >Suggested for current paragraph: >Norwegian (Bokmål) >- >None (Do not check spelling) >- >Reset to Default Language >= Can someone explain to me how in this scenario I force LO to a) use a language that I cannot currently set (because it's not offering it to me) b) use a language I haven't recently used because LO never offers it c) doesn't suggest because it thinks Gaelic is Tibetan? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #67 from daniel.scha...@gmail.com --- The point of "recent languages" is that those would be languages the users chose themselves (for the current document). But, I get that showing only "languages currently in use" has its appeal too. Although ... since we are all likely to use screens with higher resolutions than 800x600 px ... why not have both, languages currently in use, and recently used languages? = Language(s) used in current document/selection/paragraph: English (UK) ☑ French (France) More ... - Recently used languages: Some Language Some other language Yet another language - Suggested for current paragraph: Norwegian (Bokmål) - None (Do not check spelling) - Reset to Default Language = I love that the language for the current selection is indicated by a check mark and in the status bar. This should be extended to the language lists "For Paragraph" and "For All Languages". Regardless of what people prefer, recent languages with a check mark for the current language, or only languages currently in use, we need consistency. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161082] Print dialog: Put initial focus to "Printer" combobox
https://bugs.documentfoundation.org/show_bug.cgi?id=161082 --- Comment #4 from Justin L --- -1 that would be awful. Every time I print I set the printing options once, and then print multiple times, changing only the number of pages to print (and the range of pages to print). The number of copies to print is the most important setting for me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161223] basic HTML cell render
https://bugs.documentfoundation.org/show_bug.cgi?id=161223 --- Comment #11 from Eike Rathke --- This should by no means go into the formula expression engine, a spreadsheet function would be a wrong approach to render things. Instead, a cell attribute could indicate that the cell content or formula result is to be rendered taking HTML (or whatever) elements into account. Bear in mind that would add _yet another_ formatting layer somewhere in between or on top of conditional formatting hard cell attribution cell styles and possibly upcoming table styles that would go between cell styles and hard cell attribution. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #66 from Heiko Tietze --- >From the ESC meeting: * there is nothing wrong with it (the library), it's just used at a wrong place (Caolan) * it's given a single word * the lib works when it's given a longer piece of text * perhaps the menu should not do any kind of guessing, either * think this would nicely with multiple paragraphs of text -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161029] Special Find presets with regular expression
https://bugs.documentfoundation.org/show_bug.cgi?id=161029 Timur changed: What|Removed |Added CC||ti...@libreoffice.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Timur --- Seems dupe to me, if not please explain. *** This bug has been marked as a duplicate of bug 38261 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #65 from Michael Bauer --- What's the point of "recent languages" if you cannot actually set the language to something sensible? It's a double bind. So I could set a section or the document to Gaelic if LO thinks it's a language I recently used. But unfortunately LO thinks I work with Welsh, Tibetan and goodness knows what else. Whatever these clever features do or are supposed to do, can we PLEASE get something implemented that allows a user to EASILY set the language for a document or selection manually that OVERRIDES whatever LO *thinks* should be the case? We can play with anything else at leisure afterwards, but this issue has been around for eons, the bug itself is 10 years old... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #64 from daniel.scha...@gmail.com --- It appears that the language list "For Selection" works in a different way than the lists "For Paragraph" and "For All Text". (see https://bugs.documentfoundation.org/show_bug.cgi?id=161344) The list "For Selection" can be populated with up to seven recently used languages, and the currently used language is indicated by a check mark. The lists "For Paragraph" and "For All Text" seem to only show languages that are actually used in the current document (except for when bug 161344 is triggered, and with the addition of the language "detected" by libexttextcat). Both lists have spacing for a check mark, but they don't use that feature. It looks like the idea of "recent languages" with a check mark for the language at the text cursor position was implemented only half way. I actually like the list of recent languages, and the check mark is very helpful. But I could live with the approach to just show "languages currently in use". Only the mixture of both approaches is confusing. I'd like to add that the language lists "For Selection" and "For Paragraph" are absent in other LibrOffice applications like Calc and Impress. The language list "For All Text" doesn't work either in these applications. I do only see my LibreOffice default language in that list, even though the currently used language is correctly shown in the status bar at the bottom. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #63 from Caolán McNamara --- I think the original idea behind the libexttextcat usage was someone pastes a paragraph of text into something and it could be used to set the likely language for it. I don't think if ever was expected to work well with a few words. Its presence in the drop down of languages is probably a bit of a red herring and just gets it the blame. Populating the list of suggested languages via some totally other mechanism of languages used in the document and/or/+ n last languages used ever. And offering "guess language" as a totally unrelated command, or submenu from the other list, might help. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 Heiko Tietze changed: What|Removed |Added CC||caolan.mcnamara@collabora.c ||om --- Comment #62 from Heiko Tietze --- Caolan, what do you think? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #61 from Michael Bauer --- I don't think libexttextcat is beyond repair but I have always been told off for trying to tackle more than one (however connected) issue in one bug, so I'm trying to stick to fixing just the bit that offers up the wrong languages. But since you ask, I think libexttextcat could easily be made loads better by restricting it's options i.e. at the moment, it tries for ALL the languages it can potentially tag. And gets it spectacularly wrong. But if there was a way for the user to say "I normally only handle docs in languages A, B and F" then if libexttextcat was restricted to differentiating only those n languages, it should work much better. I'm sure it would struggle to an extent with closely related stuff like Bokmal and Nynorsk but would overall perform much better nonetheless. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 95274] Wrong editing languages offered
https://bugs.documentfoundation.org/show_bug.cgi?id=95274 --- Comment #60 from Heiko Tietze --- (In reply to Michael Bauer from comment #59) > >2.) Languages that the user has *explicitly* specified > > I would welcome such an option but didn't think such a dialogue option would > get much support. This ultimately means to get rid of libexttextcat and to let the user decide manually. Could imagine to have checkboxes with the Default Languages dropdowns instead of the green check marks today. And if checked, you get this language in the selection. The sorting order is another topic. If we want to keep the check mark thingy, guess it becomes visible if the language has a corresponding dictionary installed via extension, we may do so. But I'd just drop that confusing mix of configurations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161304] context menu "Delete ~Columns" deletion needlessly duplicates ~Cut mnemonic "C", allow auto assignment for the Columns entry
https://bugs.documentfoundation.org/show_bug.cgi?id=161304 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org Keywords|needsUXEval |difficultyBeginner, ||easyHack, skillDesign, ||topicDesign --- Comment #5 from Heiko Tietze --- (In reply to V Stuart Foote from comment #4) > The key sequence is by column's context menu (right mouse) -> C, or + > S -> C via the sheet menu. It is menu key (at least on my keyboard left of the right ctrl key) and 2x C. > In this case, simply resolved by removing the "~" from the "Delete ~Columns... Sounds okay but we should keep the ~Cut fix at the well established alt+C. Ultimately still NAB but no objection to drop the mnemonic on ~Column. officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu -> .uno:DeleteColumns -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160735] Change any style from a single window
https://bugs.documentfoundation.org/show_bug.cgi?id=160735 --- Comment #11 from Heiko Tietze --- (In reply to gris...@zaclys.net from comment #9) > This is exactly what I dreamed of! :) Probably not. My idea extends the editing of _one_ style with the creation of a children. I see no way to edit, for example, Text Body and to create a new style under Heading. I wonder if such thing is worth the trouble. Some implementation effort, lowering for usability, documentation, etc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 157580] Allow notebookbar and groupedbarcompact groups sections to be shown/hidden based on available space instead of only their order
https://bugs.documentfoundation.org/show_bug.cgi?id=157580 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|REOPENED|NEW --- Comment #14 from Heiko Tietze --- Rather than introducing a complex calculation I would make the widget itself resize on small screens / window sizes so it shrinks to only one style width. Anyway, I think we can agree on the fact that a large unfilled are is odd. -- You are receiving this mail because: You are on the CC list for the bug.
