https://bugs.documentfoundation.org/show_bug.cgi?id=62063
--- Comment #27 from Eyal Rozenberg <eyalr...@gmx.com> --- (In reply to Heiko Tietze from comment #26) > Had a long discussion with Hossein about this ticket (who thinks this is a > plain bug) and related topics. As UX input was requested we have to consider > the whole picture. Unless it was a face-to-face/audio/video discussion, please try to have these on the LTR channel :-) > 1. Of course we can change the three scripts concept etc. etc. Mike, see what you did? You got Heiko to veer completely out of scope :-) Heiko, if we try to solve world peace and cold fusion first we'll certainly not resolve a bug which is independent of this effects. In fact, I won't even reply to the point you're making, here, to not derail the discussion. > 2. I will reply here _only_ in the context of fixing this bug, not beyond that. > The most focal issue is that typing with a non-English character set > should be recognized and have an effect on the text. It's expected that > entering ABC makes this part English, Not really, because many language have these three glyphs - most European languages in fact. (And when I say languages, I mean language-country combinations, if we're not treating those separately) > АБГ becomes Russian, Again, many languages (or language-country pairs): https://en.wikipedia.org/wiki/Cyrillic_alphabets > and ابت magically Arabic (ideally with the right country taken from locale). Disagree with taking anything from the locale. Instead, we should take this information from the chosen keyboard layout. That's the mechanism which DEs offer us to handle input in multiple languages(/multiple language-countries). A keyboard layout corresponds to a language(+country), not just to an alphabet/script - and the user selects it knowingly and carefully. No magic. > The appropriate > font should be used, paragraph and character settings applied, and all tools > including dictionaries just work properly. MSO works like this and changes > the input language depending on the typed characters. Does it ignores the chose keyboard layout and only consider the character typed? > Con: The language is part of the PS and the CS It isn't. Or rather, in LO, it sort of is right now, but that's just a bug which needs to be fixed. That's not a con of tracking the keyboard layout. Let's fix that. Until it's fixed, let's ignore this fact for the purpose of having the font family combo-box track things. Actually, we're already ignoring it, since once you type a CTL character, the tracking changes. >, as well as direct formatting. Once we make language not-formatting, this consideration automagically goes away. > Switching magically makes it harder to understand the concept. If you stick the keyboard layout, there is no magic - the user has consciously done this themselves. It is very easy to understand. (But things might get less intuitive when you set the language manually in LO, either after typing, as in 148257, or before typing, e.g. > Pro: Convenience and usability; and we could keep the language if defined > somehow > Remark: The task to detect the language is likely not trivial. Again, it's been taken care of already. We just need to not throw away this information. So, bottom line - this bug should, and can, just be fixed irrespective of deep philosophizing on language groups and whether language is in the style or not. -- You are receiving this mail because: You are the assignee for the bug.
