https://bugs.documentfoundation.org/show_bug.cgi?id=151290
Eyal Rozenberg <eyalr...@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|A language must not be a |A language must be a
|feature of a |feature of text content,
|character/paragraph style |not of character/paragraph
| |styles
--- Comment #9 from Eyal Rozenberg <eyalr...@gmx.com> ---
(In reply to ajlittoz from comment #8)
> 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.
This is a good point, but there are actually three separate issues here:
* Text with no language
* Languages for programming and other specific domains rather than languages
developed for general-purpose speech and writing.
* Text in arbitrary languages LibreOffice does not know about apriori.
> I don't like either the idea to retrieve current
> language from keyboard layout.
I don't believe that was suggested in the context of this bug. The effect of
the chosen keyboard layout on the entered text's language is an interesting
discussion to have, but let's not have it in this bug.
> Auto-detecting current language based on glyph seems to me infeasible:
It's indeed quite infeasible. However, in the context of "filling in" language
tagging for a document we obtain with no-language-tagging - that might be a
reasonable "limited-effort" heuristic. At any rate - doing so is also a matter
for another, dependent, bug :-)
> 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.
Well, there's some similarity in how typesetting is handled: A lot of
glyph-joining. OTOH, there are ligatures in Latin/Western languages too... as
for "Asian" languages - those are the ideogramic ones, so again, similarity in
handling. But it's basically historical reasons.
> 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.
Indeed. We need more of the LO community to realize the significance and
necessity of this fundamental change, for it to gather enough momentum to be
executed.
> 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).
We will have compatibility considerations for the UI, and compatibility
considerations for the document markup, and both must be handled with some
care.
--
You are receiving this mail because:
You are the assignee for the bug.
