https://bugs.documentfoundation.org/show_bug.cgi?id=133918
--- Comment #14 from [email protected] <[email protected]> --- (In reply to Eike Rathke from comment #11) Ok, I have played some more with the widget and have a theory, although I would need somebody more versed in the LO codebase to weigh in. > "in" that should match "Inglés" in Spanish UI and for some reason did not > and was changed to "id" instead; no adhoc idea why because BCP47 language I started by checking the behavior of the language selector with English locale (LC_ALL=C) and it's the same - typing 'in' gets immediately changed to 'id' even though it should match "Indonesian" by the same logic. But if you happen to be able to type "Ind" (eg. by copying and pasting it) it does get autocompleted to "Indonesian". Meaning that the Spanish locale is not part of the problem. I then tried to follow the overall flow of the code, but sadly I'm nowhere near proficient in C++ enough to understand where the combobox logic is defined (in particular, I would think that rControl.find_text(aStr) has to return -1 for the BCP47 substitution to happen, but I can't find the definition of find_text anywhere). However, that gave me an idea: What might be happening is that the modification of the text that is part of the autofilling is triggering two different edit events, one with the full text and one without. So when you enter "in" it does get autocompleted to "Indonesian", "Inglés" or whatever, but internally that triggers another change event with just "in" as the contents which then gets changed to "id". You can reproduce a very similar behavior by doing the following: 1) Type _in in the combobox (does not exist) 2) Select the underscore 3) Type anything, even another underscore 4) Whatever you typed gets moved to the end of the string and 'in' gets again changed to 'id'. So if you typed another underscore you would see 'id_'. To me, that implies that the substitution is not atomic - there is a moment where the selected text is deleted before being replaced with whatever you type next, and that triggers a change event where the corresponding logic sees 'in' and changes it to 'id'. Maybe the autofilling is working in a similar way? If that is a (relatively) recent change/regression in the widget behavior, that would explain why I had the impression that the change was recent, even though the underlying code seems to have had no significant changes in 7+ years. (PS: You can use anything else instead of an underscore. I have used the underscore because there's a surprising amount of letters which form a valid three-letter BCP47 code when followed by 'in' and didn't want the code to be valid just in case, but you can put anything you want and the same happens.) -- You are receiving this mail because: You are the assignee for the bug.
