https://bugs.documentfoundation.org/show_bug.cgi?id=151290
--- Comment #8 from ajlittoz <page74010...@yahoo.fr> --- Let me bring my 2 cents to this debate. As mentioned in several comments, _language_ is an inherent property of text. Presently, this can only be set through a character style. But styles in general are tools to **format** text, i.e. change its appearance and flow properties. The language attribute in the Font tab mixes two layers: the abstract semantic layer associated to text significance and the "graphical" decoration layer. As pointed out in another comment, language tagging should be separate from the formatting layer. Comment #4 mentions a common usage of the Font language attribute to switch off spellchecking (e.g. for computer code). However, I think this is semantically wrong. Computer code is just another language (_None_ to avoid mistaking it for a human language) and this is too part of the data. Presently, writing multi-lingual documents is a real pain because this means duplicating styles. I don't like either the idea to retrieve current language from keyboard layout. Keyboard, for me, is a language-neutral device to enter characters. I don't practice layout switching for language switch sake because my keyboards have single engraving. I do switch layout but only because I configured various layouts for infrequent characters access, still continuing to type in the same language. Keyboard layout (again in my workflow) is only a description of the physical keyboard (I have one intl-US in addition to my locale) without implication about the language I type. Not using Font tab language attribute is a way to make styles universal. But this means language sequence is set with direct formatting, which is generally bad because there is no UI for it or visual feedback. Auto-detecting current language based on glyph seems to me infeasible: too many languages share characters (e.g. all West-European languages shares the Latin set, Japanese and Chinese share Kanji, …). I don't grasp the present notion of "groups". What is the commonality between Arabic and Hindi in the "Complex" group? Layout rules are dramatically different. What would make sense is language tagging. This should not be based on glyph. Many glyphs are "neutral", like punctuation and in some aspects "ordinary" digits. Consequently, only author's mark up can eliminate ambiguities. I acknowledge that the matter is difficult and compatibility with existing documents must be preserved. Font tab language setting could be kept for that but documentation should discourage its use as obsoleted by a new feature (separate from the formatting layer). -- You are receiving this mail because: You are the assignee for the bug.
