Le 19/07/2019 à 15:05, Jürgen Spitzmüller a écrit :
Am Freitag, den 19.07.2019, 14:46 +0200 schrieb Jean-Marc Lasgouttes:
I will. I anticipated that it would be disturbing, but I wanted to
chack
it :)
The positivist approach ;-)
And it works, I have feedback!
Do you mean with "always" the first launch of LyX? I have set the new
document language (German) in defaults.lyx, and I would be rather
distracted if LyX would reset it to whatever it perceives to be my
current "keyboard language" (which is incidentally en_US despite the
fact that I set it to de_AT in my OS).
This does not override default.lyx. Actually my thought was that it
would be nice to be able to save document without saving language, but
this is complicated UI-wise, because I do not want to be able to create
a document with "default" language.
The fact that keyboard is en_US is the sad state of Linux right now. At
least, it will be compatible with the old way.
If you do not like this when 'respect OS keyboard' if off, I can
propose
to use the current GUI language instead.
I would really have LyX respecting my defaults.lyx settings. If
defaults.lyx does not exist, the GUI language (or keyboard language, if
we can make it work under Linux) can be used as a fallback rather than
English.
Exactly my thoughts.
Another thing: currently I use Buffer::getLanguage so that, if one
writes a document partly in British English, having a en_US keyboard
would not be an issue, since the language will change to en_GB if there
is no en_US in the document. Is it a good idea, or is it
over-engineering in your eyes?
If I keep that, I may have to rewrite getLanguage which causes
performance issues in my testing. It should be integrated into
updateBuffer anyway (and toc backend should too, bu this is a different
story).
JMarc
