Problem description: While typing in Polish, every time I type in letter i (which stands for AND in Polish), it gets automatically capitalised even though Polish is set as doc language and every other word is being corrected with Polish dictionary. Steps to reproduce: 1. .... 2. .... 3. .... Current behavior: I am using Writer with UK interface and two documents languages (correction purposes): British English and Polish. Now, I temporarily set Polish as my default document language and it works fine, EXCEPT when I type “i” (which means “and” in Polish). It gets automatically capitalised as if I was typing in English even though every other word I type is treated as Polish. Settings: The document is being created in Polish, the default document language is set to Polish and status bar says Polish. This is further evidenced by auto-correction which underlines every non-Polish word while typing. Tools > Options… > Language Settings Polish is set as default document language. The interface, locale setting and currency is set to English UK. In User defined dictionaries “Standard (All)” is selected. I purged LibreOffice, deleted all config folders and installed it from scratch. The first test document (one line of text) worked fine. But in the next one the problem reappeared and won’t go away. Some previous troubleshooting: oweng wrote: _Tools_ > AutoCorrect Options… > Replace tab > scroll down to the “i -> I” entry and delete it. This entry does not exist in the Polish language table. And I do not want to delete it from English table and lose it when I am typing in English. oweng wrote: Alternatively, under the Options tab uncheck both “Use replacement table” entries. This would remove quite vital part of functionality of LibreOffice. oweng wrote: For Polish there may be additional settings under the Localized Options tab. Just two unrelated options. Operating System: Linux (Other) Version: 4.2.2.1 release Last worked in: 4.1.5.3 release
For clarity, the comments (by oweng i.e., me) quoted in the report were made in this thread: http://en.libreofficeforum.org/node/7785 I could not initially reproduce the behaviour using en-US installers (in en-AU locale): - v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 - v4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f ... under Debian 7 / Crunchbang 11 (both x86_64), with pl language pack. Now I am somewhat confused, as the problem does appear using v4.2.2.1 with pl langpack installed, but not using v4.1.4.2 with pl langpack installed. I have reset the user profiles and un/re-installed the pl langpack (and even the en-GB langpack as reported) a few times and the problem remains (under v4.2.2.1). Confirmed. Status set to NEW.
Is anyone looking into it? I saw there has been already two releases of LO with this bug in it.
Component changed to Linguistic.
Others are indicating the same issue in the related AskLO thread: http://ask.libreoffice.org/en/question/32678/
@lockheed did you try 4.2.3.3?
I just tested this bug in version 4.2.3.3. Initially, it was still there. However, when I turned the replacement table off and on again for each of the languages (British English and Australian English) I use, the problem went away. Note that I have deleted i --> I for both languages. For me at least, the problem is solved for now.
@Peter you are talking about Bug 77296 this is about auto-capitalization of "i" in non-english languages @lockheed did you check if an "i --> I" entry exists in the "All" autocorrect replacement table (first one of the list of all languages).
@tommy27, the i -> I doesn't exist in Polish replacement table, so the problem is elsewhere. However, if I set the LibreOffice interface to Polish, then the problem disappears. It only exists if the interface is English.
(In reply to comment #8) > @tommy27, the i -> I doesn't exist in Polish replacement table, so the > problem is elsewhere. I asked you to check the [All] replacement table, not the Polish. did you do that? > However, if I set the LibreOffice interface to Polish, then the problem > disappears. It only exists if the interface is English. how do you set the interface in English? I wanna replicate your exact setting. I have no autocapitalization with an Italian GUI.
>I asked you to check the [All] replacement table, not the Polish. >did you do that? I forgot how to access the replacement table and now I can't find it. >how do you set the interface in English? I wanna replicate your exact setting. >I have no autocapitalization with an Italian GUI. Tools/Options/Language Settings/Languages User Interface: English (UK) Locale setting: Default English (UK) Default languages for documents Western: Polish
(In reply to comment #10) > >I asked you to check the [All] replacement table, not the Polish. > >did you do that? > > I forgot how to access the replacement table and now I can't find it. > Tools/Autocorrect options/Replace tab then select language drop down menu and scroll all the way up to enter the [All] database
P.S. why did you put MinGW in the summary notes?
> Tools/Autocorrect options/Replace tab then select language drop down menu and > scroll all the way up to enter the [All] database The table is empty. > P.S. why did you put MinGW in the summary notes? I didn't.
ok, let's get rid of that MinGW from summary another test: try portable version and see if it's affected by same issue as the regular install... http://sourceforge.net/projects/winpenpack/files/X-LibreOffice/releases/
I am on linux.
By the way, we can change the version number of LO, because I am now on 4.2.3.3 and the bug persists.
I mean in the bug report.
no. version must indicate first version the bug appeared, not the latest.
Well, in that case the version might be even earlier than that. I am on Arch Linux so I get updates as soon as new version of Libre Office is released, and I had this issue couple of weeks before I reported it.
Confirming for 4.2.4.2 on arch. Also confirmed by a few people in http://ask.libreoffice.org/en/question/32678/i-character-keeps-getting-capitalized/ Possible regression/duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=58572
*** Bug 79346 has been marked as a duplicate of this bug. ***
issue confirmed under Windows in Bug 79346 platform -> ALL
The problem can be reproduced using different document languages, not just polish. In my case the LO interface is localized in english but when I'm editing an italian document (Tools > Language > For all text > Italian selected), the "i" word (italian plural of "the") is expanded to "I". LO version is 4.2.4.2 running on Ubuntu 14.04.
Linux-only.
(In reply to comment #24) > Linux-only. same issue reported under Windows see comment 22. anyway has any of the affected users tried LibO 4.3.2.2? is bug still there? @lockheed have you tried typing in other languages rather than Polish? do you still reproduce that bug?
Cannot reproduce in Windows, with Polish text. So bug 79346 is probably pure bogus.
I downloaded LO 4.3.2 and tested for the bug typing Polish. It looks like it is solved now.
@krzysztof are you on Windows or Linux? is there any Linux user that can retest with 4.3.2.2?
Windows 7 Pro. I also have Open Suse 12.3 but there is no 4.3.2 version for it yet.
(In reply to comment #28) > is there any Linux user that can retest with 4.3.2.2? Under Debian 7 x86_64 using v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d (en-US UI, en-AU locale) with LibreOffice_4.3.2.2_Linux_x86-64_deb_langpack_pl.tar.gz (Polish text) the problem does indeed appear resolved. Thus WORKSFORME under GNU/Linux.
OK. let's mark this as WFM. feel free to revert status to NEW if anyone still reproduce the bug with current releases.
Original bug poster here. I just upgraded from v. 4.2 to v4.3.2.2 (Arch linux). The bug is still there. Nothing changed for me.
@lockheed sorry to hear that. do you have the chance to retest on another computer with fresh new LibO installation? could it be an Arch Linux specific issue or something specific to your hardware?
I purged libreoffice installation and its user config files. Then I installed it anew. No change - the bug is still there.
Adding self to CC if not already on
*** Bug 88553 has been marked as a duplicate of this bug. ***
4.2.7.2 - 420m0 build 2 (Ubuntu version) still sees this issue.
*** Bug 88509 has been marked as a duplicate of this bug. ***
hi guys, please tell me what happens if you try to workaround the bug setting an "I to i" autocorrect replacement in your language? is this enough to avoid the unwanted "i to I" autocorrection?
(In reply to tommy27 from comment #39) > hi guys, please tell me what happens if you try to workaround the bug > setting an "I to i" autocorrect replacement in your language? > > is this enough to avoid the unwanted "i to I" autocorrection? The replacement doesn't work. Even worse, when you start a phrase with the single letter I (which should be capitalized) the I is corrected to lowercase i.
ok, try this one with wildcard autocorrection: enter this in the replace field: .* I (point - asterisk - space - I) and put this in the with field: i (space - i) this should prevent capitalization in the middle of a phrase. however it would cause the I at the beginning of the phrase to turn into i. I don't know if in your language there are circumstances in which a single capital I is used to start a sentence. if yes we may think about a second workaround for that one.
It doesn't work. What it looks like is that the i->I substitution is something "hardcoded" performed *after* the autocorrect replacements. There are instances where the I starts a phrase in Romanian. There are also instances in which (uppercase) I is used in the middle of the phrase, but they are rare and usually, i is not capitalized.
just another test from you. I want to understand what exactly kicks in this "i to I" replacement. go in the LibO user profile. location under Linux is described here: https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux go in the autocorr subfolder and temporarily delete the acor_en-US.dat or acor_en-GB.dat files that should be there. then relaunch LibO and see if the replacement still happens. if it doesn't happen anymore it's a proof that the english autocorrect database kicks in even if the language is not english. then another test: enter the autocorrect replacement table (Tools/Autocorrect options/Replace) then select language drop down menu and scroll till you find English (US) or English (GB) then verify the presence of the "I to i" replacement and ad d a new replacement like "e to E" or "a to A" and save the changes then write a sentence in your language and tell if the capitalization happens only with the i or even with the other letters you set. I have a theory... maybe when you type a single isolated letter such as "i" the document temporarily reverts the language to english (that's why the replacement kicks in) whilst when you type words with multiple letters the documents keep the original language. let me know
(In reply to tommy27 from comment #43) > just another test from you. I want to understand what exactly kicks in this > "i to I" replacement. > > go in the LibO user profile. > location under Linux is described here: > https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux > > go in the autocorr subfolder and temporarily delete the acor_en-US.dat or > acor_en-GB.dat files that should be there. > > then relaunch LibO and see if the replacement still happens. > > if it doesn't happen anymore it's a proof that the english autocorrect > database kicks in even if the language is not english. > > then another test: enter the autocorrect replacement table > (Tools/Autocorrect options/Replace) then select language drop down menu and > scroll till you find English (US) or English (GB) > > then verify the presence of the "I to i" replacement and ad d a new > replacement like "e to E" or "a to A" and save the changes > > then write a sentence in your language and tell if the capitalization > happens only with the i or even with the other letters you set. > > I have a theory... maybe when you type a single isolated letter such as "i" > the document temporarily reverts the language to english (that's why the > replacement kicks in) whilst when you type words with multiple letters the > documents keep the original language. > > let me know Hi Tommy, I'm trying with LO 4.3.3.2 on Ubuntu 14.10 and I cannot reproduce this bug any longer. I will try at work on monday where I still have an older version of LO. Concerning the first test you suggest with the acor_* file, I can't find anything under the autocorr folder in the user profile directory (but I can write english documents where "i" is correctly replaced with "I"): is this ok? Fabio
(In reply to Fabio Strozzi from comment #44) > > Hi Tommy, I'm trying with LO 4.3.3.2 on Ubuntu 14.10 and I cannot reproduce > this bug any longer. > I will try at work on monday where I still have an older version of LO. then it would be interesting to know if uprading to a recent 4.3.x releases (latest available is 4.3.5.2) will fix the bug on that machine too. > Concerning the first test you suggest with the acor_* file, I can't find > anything under the autocorr folder in the user profile directory (but I can > write english documents where "i" is correctly replaced with "I"): is this > ok? > > Fabio you are right... even if there's no enabled "acor.dat" file in the user profile the "i to I" autocorrection kicks is when you write an english text, because LibO takes the replacement from the default autocorrect datasets that are under "LibreOffice/share/autocorrect" (this is the Windows path... don't know if it's the same under Linux). indeed if I delete the acor_en.dat files from share, no "i to I" happens. however if I leave those .dat files in their place, this "i to I" replacement doesn't happen under Windows if I use non-english language, unlike multiple Linux users who reported this correction appearing in Polish, Romanian, Swedish and many other non-English languages.
I can confirm that this bug is still alive running 4.4.1rc2 on Ubuntu. I have been trying out different set ups to see when this bug is occurring. The problem seems to be related to the English locale setting. I have tested it with different combinations of UI language and locale language. My testing gave the following results (remember to restart LibreOffice every time you change the locale language, otherwise it doesn't work): UI language = English (UK): Locale language = Danish Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = German (Germany) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = French (France) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = English (UK) Result: AutoCorrect of 'i' ONLY works as it should in English, but NOT in Danish, French or German. UI language = Danish Locale language = Danish Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = French (France) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = German (Germany) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = English (UK) Result: AutoCorrect of 'i' ONLY works as it should in English and Danish, but NOT in French or German. UI language = German (Germany) Locale language = Danish Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = French (France) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = German (Germany) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = English (UK) Result: AutoCorrect of 'i' ONLY works as it should in German and English, but NOT in Danish or French. UI language = French (France) Locale language = German (Germany) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = French (France) Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = Danish Result: AutoCorrect of 'i' works as it should in English, Danish, French and German. Locale language = English (UK) Result: AutoCorrect of 'i' ONLY works as it should in English, but NOT in German, French, or Danish. Version: 4.4.1.2 Build ID: 40m0(Build:2) Locale: da_DK OS: Ubuntu 14.04 x86
I confirm this bug with 4.4 and 4.5 beta for Italian language.
Correction: 4.5 alpha (not beta as I said above) It's not enough to change the "default languages for documents" to Italian, "locale settings" must be changed too to Italian to avoid this.
*** Bug 90915 has been marked as a duplicate of this bug. ***
issue affects Windows as well and is reproducible even with LibO 5.1.0.0.alpha1+ Build ID: 62e2fae93e8894f73560a30ae1e752cbd4c001ad TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-07-29_04:40:44 Locale: en-US (it_IT) STEPS TO REPRODUCE - go in "Tools/Options/Language Settings/Languages" - select "English (USA)" as Locale Setting - select another language as Default Languages for Documents, let's say "Polish" as the first report (I tried other languages and it was the same) - open a new document and start typing some words... you'll see unwanted automatic corrections coming from the english locale the autocorrect collisions many users reported is not limited to the "i" to "I" unwanted replacement... try typing "abotu" in the Polish document and you will see that it will be corrected as "about" basically autocorrect replacements from the English Local Setting are applied even in documents using a different Default Language (in this case Polish) the bug happens when you set 2 different languages in the Locale and in the Default Document language take a look ad Bug 78912 which describes the same problem in the case you set Spanish as Locale and Portoguese as Document Default Language... you'll see Spanish autocorrect applied in the Portoguese document as well this bug is a regression and wasn not present in LibO 4.1.5.3 and appeared in LibO 4.2.0.4 so platform ALL and bibisectRequest
*** Bug 78912 has been marked as a duplicate of this bug. ***
This bug (=that the English autocorrect table is always applied for certain non-English spellchecker languages, even though the entry does not appear in the [all] table or the table for the language in question) still persists as of 5.0.12, under windows, with English interface language. My tests show that as of 5.0.12 the issue exists and can be fully reproduced, but only for some spellchecking languages. * The issue does NOT occur when the language pack is set to "none" * The issue occurs for some languages, including Danish and French (with the language packs installed) have the issue * The issue does NOT occur for all languages, including German (with language pack.) * The issue occurs for some languages, including Haitian and Frisian WITHOUT the language packs installed. When making my tests, i made sure to test multiple different words, and i checked that the words did not exist in the "all" autocorrect table or the autocorrect table for the tested language. SUMMARY The issue persists as of 5.0.12, but only for some language settings. The issue seems to be that the English autocorrect table is sometimes applied to non-english languages.
I raise priority since this annoyance can cause many issues in several languages.
is there any Linux user who wants to try bibisecting this bug? this is the only way we can start fixing it. instructions here: https://wiki.documentfoundation.org/QA/Bibisect
Tried bibisecting this bug. cloned the bibisecting-git. git clone git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily.git tried out the latest: a27f97cdc75cc1796928c5aa307152f4da15257a 1. new dokument 2. language: swedish 3. wrote: "Jag bor i Sverige", and the "i" converted to "I" switched to oldest: git checkout oldest HEAD is now at 2b392af... 2015-05-20: source-hash-90e2dabb8d0bb5382234be776c2ad0e2d5d9e224 Tried the same there, same problem. Never done a bibisecting before, but sounds like a binary-search, but to have a binary search to work, there need to be a working version at one end.
found the 43alll package for bibisect. result: git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 06793dd2acc5fe5c7dd3cecf09784c2d3426f33a 10fc65607493c257076c8af1b708839eb03d8d14 b5b034dfb3e4cd132c1e60a0283ff527ec92637a We cannot bisect more! log: $> git checkout latest HEAD is now at 423a84c... source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e $> git checkout oldest HEAD is now at 65fd30f... source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 $> git bisect start latest oldest Bisecting: 376 revisions left to test after this (roughly 9 steps) [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb $> git bisect good Bisecting: 188 revisions left to test after this (roughly 8 steps) [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b $> git bisect bad Bisecting: 93 revisions left to test after this (roughly 7 steps) [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 ERROR 4 forking process $> git bisect skip Bisecting: 93 revisions left to test after this (roughly 7 steps) [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a $> git bisect skip Bisecting: 93 revisions left to test after this (roughly 7 steps) [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 $> git bisect bad Bisecting: 66 revisions left to test after this (roughly 6 steps) [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217 $> git bisect good Bisecting: 32 revisions left to test after this (roughly 5 steps) [89110ca258fa7a15dfc546acfb39e76fc3eb2a44] source-hash-e450a2c506ac7cd4433b0f93fc750a89919bc03c $> git bisect skip Bisecting: 32 revisions left to test after this (roughly 5 steps) [1cca92a409385d9288c28a54d5e3008e56728bc0] source-hash-7be7824bbbdeee6fa998b950e6046ab37fe690cb $> git bisect good Bisecting: 30 revisions left to test after this (roughly 5 steps) [5fa28ce2931a35ae64ae08d3904cfb76d24459d8] source-hash-2304beaca33c63b94df99cb827716f00ce259f9a $> git bisect skip Bisecting: 30 revisions left to test after this (roughly 5 steps) [2a9ff869c5638dc5c3aa387d0fe55c3291c86288] source-hash-01b7e04172889cbc9e4ac404b105e18ddc062d6f $> git bisect bad Bisecting: 17 revisions left to test after this (roughly 4 steps) [9771d0c212cfa71b07742ff3dc5c05df22d600eb] source-hash-a9a0933ec67eab0ec31c8fadb60fb8e8e3e90485 $> git bisect bad Bisecting: 8 revisions left to test after this (roughly 3 steps) [b68886f4c56ebc4cdf94aee9753398ccce28bb41] source-hash-90830788b1f8fd61ea86135712868aeda395edd0 $> git bisect good Bisecting: 3 revisions left to test after this (roughly 2 steps) [06793dd2acc5fe5c7dd3cecf09784c2d3426f33a] source-hash-2232781ad303864b79a3973b5b0eec40a859a701 $> git bisect skip Bisecting: 3 revisions left to test after this (roughly 2 steps) [10fc65607493c257076c8af1b708839eb03d8d14] source-hash-1500aae993c0a8b4fa9a5bcec1bc6203f3bcff66 $> git bisect skip Bisecting: 3 revisions left to test after this (roughly 2 steps) [e3a648fdaa2bb87293750400b70ba590733a804a] source-hash-33526481788137d959f27ae32910127d1436c1a8 $> git bisect good Bisecting: 3 revisions left to test after this (roughly 2 steps) [50f1f06ed2dd40d2e6f658524a5e160ba1a84807] source-hash-647fb29f528b891a1c92846640f7865f5c1fbe7f /opt/program/soffice: line 161: /home/puggan/src/lo/bibisect/bibisect-43all/opt/program/oosplash: No such file or directory $> git bisect skip Bisecting: 3 revisions left to test after this (roughly 2 steps) [b5b034dfb3e4cd132c1e60a0283ff527ec92637a] source-hash-b95acb2bdcc6bc7c09a806157361c83142858d97 $> git bisect bad Bisecting: 1 revision left to test after this (roughly 1 step) [ab05d0f440b5ac5f1f6481a70c9840292aafde2e] source-hash-f86404450621bbee6feaaee0f43f5e53d9501796 $> git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 06793dd2acc5fe5c7dd3cecf09784c2d3426f33a 10fc65607493c257076c8af1b708839eb03d8d14 b5b034dfb3e4cd132c1e60a0283ff527ec92637a We cannot bisect more!
I'm not expert analyzing bibisect data but I think you should bibisect the 4.2 branch since the bug first appeared in 4.2.0.4 release
# good: [ab05d0f440b5ac5f1f6481a70c9840292aafde2e] source-f86404450621bbee6feaaee0f43f5e53d9501796 # possible first bad commit: [b5b034dfb3e4cd132c1e60a0283ff527ec92637a] source-hash-b95acb2bdcc6bc7c09a806157361c83142858d97 # possible first bad commit: [06793dd2acc5fe5c7dd3cecf09784c2d3426f33a] source-hash-2232781ad303864b79a3973b5b0eec40a859a701 # possible first bad commit: [10fc65607493c257076c8af1b708839eb03d8d14] source-hash-1500aae993c0a8b4fa9a5bcec1bc6203f3bcff66 So somewhere between source-hash-f86404450621bbee6feaaee0f43f5e53d9501796 http://cgit.freedesktop.org/libreoffice/core/commit/?id=f86404450621bbee6feaaee0f43f5e53d9501796 and source-hash-b95acb2bdcc6bc7c09a806157361c83142858d97 http://cgit.freedesktop.org/libreoffice/core/commit/?id=b95acb2bdcc6bc7c09a806157361c83142858d97 so next step is to clone the source, and bisect between thous 2?
After bisecting the source, i got the result: "df0f34cb9c036f5cf69b72a740c1a8f2741ac966 is the first bad commit" http://cgit.freedesktop.org/libreoffice/core/commit/?id=df0f34cb9c036f5cf69b72a740c1a8f2741ac966
I rise importance since this issue affects many languages and can prevent correct writing because of this unwanted automatic correction. I put Writer expert on CC list to see if he can analyze the bibisect results.
I put on CC list also a developer who's expert in the field of autocorrection too. @Micheal and Lazlo who's gonna take a look at this buddy?
I fail to understand why did it take 1,5 year to do those things described in the comments from the last month. Seem like the most basic things that should have been taken care of 18 months ago.
@lockheed why didn't you do it yourself? instead of ranting, please to something concrete and useful to help solving the issue
@tommy27 - do something concrete and useful to help solving the issue? You mean, like, say, being the very person who first reported and filed this bug 18 months ago? And then getting Owen Genat to provide even more details on the issue? And why didn't I raised the priority? I did the very thing when opening the bug. I have no influence on other people degrading its priority afterwards. And why didn't I add some people to CC list myself? Because I have no clue who should be on this list. I'm just a user who registered just to file an important bug he found. So the last concrete thing I can do here is to ask this: Since you are the person who knows those experts, why did it take you 1,5 year to interest them in this critical issue?
(In reply to lockheed from comment #64) > @tommy27 > > ... > > And why didn't I raised the priority? I did the very thing when opening the > bug. I have no influence on other people degrading its priority afterwards. > And why didn't I add some people to CC list myself? Because I have no clue > who should be on this list. I'm just a user who registered just to file an > important bug he found. I'm just an user too, and I do volunteer work helping the QA team. I did not have any clue how to process bugs when I started, but I wanted to learn and I spent time reading the Wiki, talking to devs and QA member in the mailing lists and forums there's a wiki where you could have read how to properly report bugs etc. etc. https://wiki.documentfoundation.org/QA/BugTriage ignorance is not an excuse. > So the last concrete thing I can do here is to ask this: Since you are the > person who knows those experts, why did it take you 1,5 year to interest > them in this critical issue? you still do useless ranting... it seems to me that you are looking for someone to spoonfeed yourself... this is not how thing work in this LibO project. so, please stop this silly rant. if you dont't have constructive comments that may help fix the issue, please shut up.
by the way, thanks to Puggan SE who really did some good job doing the bibisect.
(In reply to tommy27 from comment #65) > I'm just an user too, and I do volunteer work helping the QA team. > I did not have any clue how to process bugs when I started, but I wanted to > learn and I spent time reading the Wiki, talking to devs and QA member in > the mailing lists and forums Good for you. What does it have to do with me? I have no interest nor time to process bugs. I am no volunteer nor do I help the team in any other way than reporting a bug I encounter. Is it an obligation for someone who reports a bug to become a volunteer and go learn all those things? No? So what is the point of writing about it other than having a feeling you are right because you wrote something? Being right doesn't work like that. > there's a wiki where you could have read how to properly report bugs etc. > etc. > Ignorance of what? And excuse from what exactly? Pointing out that this issue has received poor attention? > you still do useless ranting... > it seems to me that you are looking for someone to spoonfeed yourself... > this is not how thing work in this LibO project. Spoonfeed? Do you understand meanings of words you are using? In order to be spoonfed one needs to have some (usually easily self-filled) need, expressed with a question, and expectation for somebody to answer that question. I do not recall asking for anything nor expressing any need so please stop using words and arguments that have no application to what you (try to) respond to. This seem to be your whole theme - to say things that have nothing to do with the discussion, just to say something. There are wikis and other resources online where you can learn how to construct a non-nonsensical arguments and responses, eg: http://virtualschool.edu /mon/SocialConstruction/Logic.html Ignorance is not an excuse. If you do not know how to rant, or respond to a rant, or construct a working, logical response of any kind to what someone wrote, do not attempt it. EOT
Can we please just tone down the rhetoric and move on. The bug is reported and confirmed - a volunteer will fix it (or not) at some point.
export LANG=en_GB.UTF-8 launch writer set format character to Polish put break point in SvxAutoCorrect::SearchWordsInList at the use of nTmpKey2 = eLang & 0x3ff The lang will be 0x415 for polish, nTmpKey2 will be 0x15, but the aLanguageTag after reset is getting resolved to "maBcp47 = "en-GB", mnLangID = 21" I don't know if the identification of df0f34cb9c036f5cf69b72a740c1a8f2741ac966 is correct, but its definitely the LanguageTag resolving that triggers this. Hacking out that entire nTmpKey2 usage branch gives the expected result of no capitalized with en-GB rules of the i
consider that this happens not only with Polish but with other languages as well see comment 23 and comment 46
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1ff0745cc4f78777e8dba1e7bb52d18386d7394 Resolves: tdf#76964 fall back to primary language via getLanguage It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
https://gerrit.libreoffice.org/19545 5.0.X backport
@Caòlan thank you very much for fixing this one!!!
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=97893e56e61a466e56d12ee46d11f6e4c32a737b more tdf#76964 fall back to primary language via getLanguage It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de1cb4039756f71d848297981b757c1cfa4609b1&h=libreoffice-5-0 Resolves: tdf#76964 fall back to primary language via getLanguage It will be available in 5.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]