Bug 76964 - Automatic capitalization of "i" in a non-english language
Summary: Automatic capitalization of "i" in a non-english language
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: highest major
Assignee: Eike Rathke
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords: bibisected, regression
: 78912 79346 88509 88553 90915 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-02 19:29 UTC by lockheed
Modified: 2016-10-25 19:20 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lockheed 2014-04-02 19:29:31 UTC
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
Comment 1 Owen Genat (retired) 2014-04-03 07:19:16 UTC
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.
Comment 2 lockheed 2014-04-17 09:54:19 UTC
Is anyone looking into it? I saw there has been already two releases of LO with this bug in it.
Comment 3 Owen Genat (retired) 2014-04-20 08:45:01 UTC
Component changed to Linguistic.
Comment 4 Owen Genat (retired) 2014-04-30 12:26:22 UTC
Others are indicating the same issue in the related AskLO thread: http://ask.libreoffice.org/en/question/32678/
Comment 5 tommy27 2014-05-05 22:16:55 UTC
@lockheed
did you try 4.2.3.3?
Comment 6 peter 2014-05-06 00:11:25 UTC
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.
Comment 7 tommy27 2014-05-06 05:06:53 UTC
@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).
Comment 8 lockheed 2014-05-06 07:33:37 UTC
@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.
Comment 9 tommy27 2014-05-06 07:38:23 UTC
(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.
Comment 10 lockheed 2014-05-06 07:44:44 UTC
>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
Comment 11 tommy27 2014-05-06 07:49:02 UTC
(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
Comment 12 tommy27 2014-05-06 07:49:30 UTC
P.S. why did you put MinGW in the summary notes?
Comment 13 lockheed 2014-05-06 14:40:30 UTC
> 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.
Comment 14 tommy27 2014-05-06 20:48:35 UTC
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/
Comment 15 lockheed 2014-05-06 21:00:51 UTC
I am on linux.
Comment 16 lockheed 2014-05-06 21:01:52 UTC
By the way, we can change the version number of LO, because I am now on 4.2.3.3 and the bug persists.
Comment 17 lockheed 2014-05-06 21:02:08 UTC
I mean in the bug report.
Comment 18 tommy27 2014-05-06 21:10:18 UTC
no. version must indicate first version the bug appeared, not the latest.
Comment 19 lockheed 2014-05-06 21:12:45 UTC
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.
Comment 20 confirming-bug-i-I 2014-05-18 12:32:45 UTC
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
Comment 21 tommy27 2014-05-28 18:30:40 UTC
*** Bug 79346 has been marked as a duplicate of this bug. ***
Comment 22 tommy27 2014-05-28 18:31:48 UTC
issue confirmed under Windows in Bug 79346
platform -> ALL
Comment 23 Fabio Strozzi 2014-07-10 12:45:33 UTC
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.
Comment 24 Urmas 2014-07-12 02:22:36 UTC
Linux-only.
Comment 25 tommy27 2014-09-28 06:51:06 UTC
(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?
Comment 26 Urmas 2014-09-28 19:34:51 UTC
Cannot reproduce in Windows, with Polish text. So bug 79346 is probably pure bogus.
Comment 27 krzysztof 2014-09-29 00:26:38 UTC
I downloaded LO 4.3.2 and tested for the bug typing Polish. It looks like it is solved now.
Comment 28 tommy27 2014-09-29 05:35:33 UTC
@krzysztof
are you on Windows or Linux?
is there any Linux user that can retest with 4.3.2.2?
Comment 29 krzysztof 2014-09-29 06:38:32 UTC
Windows 7 Pro. I also have Open Suse 12.3 but there is no 4.3.2 version for it yet.
Comment 30 Owen Genat (retired) 2014-09-29 11:40:14 UTC
(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.
Comment 31 tommy27 2014-09-29 11:42:30 UTC
OK. let's mark this as WFM.
feel free to revert status to NEW if anyone still reproduce the bug with current releases.
Comment 32 lockheed 2014-09-30 07:36:15 UTC
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.
Comment 33 tommy27 2014-09-30 08:23:46 UTC
@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?
Comment 34 lockheed 2014-09-30 08:39:41 UTC
I purged libreoffice installation and its user config files. Then I installed it anew. No change - the bug is still there.
Comment 35 Alex Thurgood 2015-01-03 17:38:57 UTC
Adding self to CC if not already on
Comment 36 tommy27 2015-01-18 15:52:21 UTC
*** Bug 88553 has been marked as a duplicate of this bug. ***
Comment 37 Dorin Lazăr 2015-01-18 16:07:25 UTC
4.2.7.2 - 420m0 build 2 (Ubuntu version) still sees this issue.
Comment 38 tommy27 2015-01-18 18:12:05 UTC
*** Bug 88509 has been marked as a duplicate of this bug. ***
Comment 39 tommy27 2015-01-23 04:55:05 UTC
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?
Comment 40 Dorin Lazăr 2015-01-23 05:19:26 UTC
(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.
Comment 41 tommy27 2015-01-23 06:18:57 UTC
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.
Comment 42 Dorin Lazăr 2015-01-23 06:42:59 UTC
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.
Comment 43 tommy27 2015-01-23 07:25:17 UTC
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
Comment 44 Fabio Strozzi 2015-01-24 15:47:20 UTC
(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
Comment 45 tommy27 2015-01-25 18:11:57 UTC
(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.
Comment 46 Henrik 2015-02-25 19:14:07 UTC
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
Comment 47 Armando Villani 2015-04-10 12:31:09 UTC
I confirm this bug with 4.4 and 4.5 beta for Italian language.
Comment 48 Armando Villani 2015-04-10 12:36:22 UTC
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.
Comment 49 Kristoffer Ryhl-Johansen 2015-04-29 05:11:40 UTC
*** Bug 90915 has been marked as a duplicate of this bug. ***
Comment 50 tommy27 2015-07-31 22:33:40 UTC
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
Comment 51 tommy27 2015-07-31 22:36:18 UTC
*** Bug 78912 has been marked as a duplicate of this bug. ***
Comment 52 Jack 2015-09-08 12:19:02 UTC
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.
Comment 53 tommy27 2015-09-08 15:33:14 UTC
I raise priority since this annoyance can cause many issues in several languages.
Comment 54 tommy27 2015-10-15 05:21:00 UTC
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
Comment 55 Puggan SE 2015-10-15 21:21:40 UTC
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.
Comment 56 Puggan SE 2015-10-16 07:12:11 UTC
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!
Comment 57 tommy27 2015-10-16 07:21:28 UTC
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
Comment 58 Puggan SE 2015-10-16 20:47:49 UTC
# 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?
Comment 59 Puggan SE 2015-10-19 17:37:24 UTC
After bisecting the source, i got the result:
"df0f34cb9c036f5cf69b72a740c1a8f2741ac966 is the first bad commit"

http://cgit.freedesktop.org/libreoffice/core/commit/?id=df0f34cb9c036f5cf69b72a740c1a8f2741ac966
Comment 60 tommy27 2015-10-20 03:52:00 UTC
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.
Comment 61 tommy27 2015-10-21 15:01:17 UTC
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?
Comment 62 lockheed 2015-10-21 15:34:35 UTC
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.
Comment 63 tommy27 2015-10-21 16:05:15 UTC
@lockheed
why didn't you do it yourself?

instead of ranting, please to something concrete and useful to help solving the issue
Comment 64 lockheed 2015-10-21 16:21:47 UTC
@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?
Comment 65 tommy27 2015-10-21 16:37:25 UTC
(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.
Comment 66 tommy27 2015-10-21 16:38:35 UTC
by the way, thanks to Puggan SE who really did some good job doing the bibisect.
Comment 67 lockheed 2015-10-21 17:24:04 UTC
(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
Comment 68 Joel Madero 2015-10-21 17:45:46 UTC
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.
Comment 69 Caolán McNamara 2015-10-22 19:50:23 UTC
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
Comment 70 tommy27 2015-10-23 01:31:05 UTC
consider that this happens not only with Polish but with other languages as well
see comment 23 and comment 46
Comment 71 Commit Notification 2015-10-23 08:14:11 UTC
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.
Comment 72 Caolán McNamara 2015-10-23 08:19:39 UTC
https://gerrit.libreoffice.org/19545 5.0.X backport
Comment 73 tommy27 2015-10-23 08:27:23 UTC
@Caòlan
thank you very much for fixing this one!!!
Comment 74 Commit Notification 2015-10-23 19:28:59 UTC
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.
Comment 75 Commit Notification 2015-11-06 09:08:21 UTC
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.
Comment 76 Robinson Tryon (qubit) 2015-12-17 07:55:23 UTC Comment hidden (obsolete)