Bug 127722 - Misleading language id text on UI
Summary: Misleading language id text on UI
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on: 103405
  Show dependency treegraph
Reported: 2019-09-23 16:03 UTC by Kovács Viktor
Modified: 2020-02-23 13:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

Screenshot of the misleading settins text. (177.44 KB, image/jpeg)
2019-09-23 16:03 UTC, Kovács Viktor

Note You need to log in before you can comment on or make changes to this bug.
Description Kovács Viktor 2019-09-23 16:03:27 UTC
Created attachment 154390 [details]
Screenshot of the misleading settins text.

There are misleading CTL setting name as [None]. It (NOW) implements Old Hungarian script. It would be id as other non-fully implemented in the future.

It would be better, if UI text appear as "under introduction" or something else.
"None" text suggest, that sets no one of languages, and it isn't work.

For testing Old Hungarian cappabilities:
Suitable font:

Suitable keyboard layout in xkeyboard-config defined since 2.22 version released between  extras - for Linux. (Updated it in version 2.27)
Suitable keyboard layout for Windows (It compatible with xkeyboard-layout's version 2.27):
Comment 1 Kovács Viktor 2019-09-23 16:09:32 UTC

What's your opinion?
Comment 2 V Stuart Foote 2019-09-23 16:29:37 UTC
Not too many options here. Until bug 103405 is completed, there is no other choice than a 'None' entry on the Tools -> Options -> Language Settings -> Languages for the Complex Text layout handling. Can not apply to an entire document.

Otherwise, the Character dialog allows you to assign a supported font (e.g. Kende) and select a 'Hungarian (Szekely-Hungarian Rovas) language assignment for ODF markup of paragraphs and text runs, while the ICU libs correctly will handle bidi and rendering of Hungarian entered RTL as rovas for Unicode in the x10c80-x10cff range.

Seems IMHO a => WF and efforts should proceed on bug 103405