Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Am Samstag, 4. August 2018 07:02:53 CEST schrieb Jürgen Spitzmüller : > Am Freitag, den 03.08.2018, 21:17 +0200 schrieb Kornel Benko: > > Probably. Calling > > check_layout beamer ,x > > creates the file ",x", but the relevant content is mangled (missing > > 'End'-prefix) > > ... > > IsAutoNestedBy > > Enumerate,Itemize > > IsAutoNestedBy > > ... > > > > The attached cures check_layout. > > Right, that's the bug. A typo of mine. Could you please commit? This > also needs to go to stable. > > Thanks, > Jürgen > Done at 5c303ab. Kornel signature.asc Description: This is a digitally signed message part.
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Am Freitag, den 03.08.2018, 21:17 +0200 schrieb Kornel Benko: > Probably. Calling > check_layout beamer ,x > creates the file ",x", but the relevant content is mangled (missing > 'End'-prefix) > ... > IsAutoNestedBy > Enumerate,Itemize > IsAutoNestedBy > ... > > The attached cures check_layout. Right, that's the bug. A typo of mine. Could you please commit? This also needs to go to stable. Thanks, Jürgen > > Kornel signature.asc Description: This is a digitally signed message part
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Am Freitag, 3. August 2018 20:01:04 CEST schrieb Jürgen Spitzmüller
:
> Am Freitag, den 03.08.2018, 19:04 +0200 schrieb Kornel Benko:
> > LyX: Long string not ended by `EndIsAutoNestedBy'
> > [around line 56 of file current token: '' context: '']
> > Could not read style NoteItem.
>
> But this is the case (it is ended by `EndIsAutoNestedBy'). Is this a
> bug in the layout test?
>
> Jürgen
>
Probably. Calling
check_layout beamer ,x
creates the file ",x", but the relevant content is mangled (missing
'End'-prefix)
...
IsAutoNestedBy
Enumerate,Itemize
IsAutoNestedBy
...
The attached cures check_layout.
Kornel
diff --git a/src/Layout.cpp b/src/Layout.cpp
index 7801e8f..2f3d1b9 100644
--- a/src/Layout.cpp
+++ b/src/Layout.cpp
@@ -1439,11 +1439,11 @@ void Layout::write(ostream & os) const
it != autonested_by_.end(); ++it) {
if (it != autonested_by_.begin())
os << ',';
os << to_utf8(*it);
}
- os << "\n\tIsAutoNestedBy\n";
+ os << "\n\tEndIsAutoNestedBy\n";
}
if (refprefix.empty())
os << "\tRefPrefix OFF\n";
else
os << "\tRefPrefix " << to_utf8(refprefix) << '\n';
signature.asc
Description: This is a digitally signed message part.
Re: Installation of Lyx on Windows
Le 3 août 2018 19:34:56 Richard Kimberly Heck a écrit : I hadn't seen it before, but I'm planning to kill off the bundle for 2.3.1 anyway. Great idea! -- Jean-Pierre
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Am Freitag, den 03.08.2018, 19:04 +0200 schrieb Kornel Benko: > LyX: Long string not ended by `EndIsAutoNestedBy' > [around line 56 of file current token: '' context: ''] > Could not read style NoteItem. But this is the case (it is ended by `EndIsAutoNestedBy'). Is this a bug in the layout test? Jürgen signature.asc Description: This is a digitally signed message part
Strings Frozen for 2.3.1
I've asked our translators to do their work for 2.3.1, so no string-changing commits to 2.3.x until the release. Riki
Re: Installation of Lyx on Windows
On 08/03/2018 10:54 AM, Jean-Pierre wrote: > Hello > > A French user tried to install the official lyx-2.3.0 bundle and > complained on lyx-fr that no classes were present. > I suggested to install MiKTeX first and use the installer instead of > the bundle. That was successful. > > Is this beavior known? I hadn't seen it before, but I'm planning to kill off the bundle for 2.3.1 anyway. Riki
Re: [LyX/master] Do not increment start for find(phrase) while looping over phrases
On 08/02/2018 04:57 PM, Kornel Benko wrote: > Am Donnerstag, 2. August 2018 22:56:50 CEST schrieb Kornel Benko > : >> commit a96845660eccd9feee738e56215377ac14a41ceb >> Author: Kornel Benko >> Date: Thu Aug 2 22:51:36 2018 +0200 >> >> Do not increment start for find(phrase) while looping over phrases >> >> The increment will be done at the end of the for-loop. >> --- >> lib/lyx2lyx/lyx_2_2.py |1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py >> index 5f21a7c..d8d9ab6 100644 >> --- a/lib/lyx2lyx/lyx_2_2.py >> +++ b/lib/lyx2lyx/lyx_2_2.py >> @@ -758,7 +758,6 @@ def convert_phrases(document): >> for phrase in phrases: >> j = document.body[i].find(phrase) >> if j == -1: >> -i += 1 >> continue >> if not is_part_of_converted_phrase(document.body[i], j, phrase): >> front = document.body[i][:j] >> > Candidate for 2.3.x OK. rkh
Re: templates/RJournal.lyx not compilable
Am Freitag, 3. August 2018 17:42:14 CEST schrieb Jürgen Spitzmüller : > Am Freitag, den 03.08.2018, 11:21 -0400 schrieb Scott Kostyshak: > > Another question that I saw come up is: should the LyX display be the > > same as the PDF output? From what I understand, before the change, > > the > > LyX display was localized to the GUI language, but the LaTeX output > > was > > not localized. Now, both are localized. > > No, the output was also localized before. I was not aware of this part. > But the languages were not > correctly marked. Just open an English manual in LyX 2.3 with a German > (or French) UI language. > > > In other words, before the > > change, GP2 was violated but GP1 was not. Now it is the opposite: GP1 > > is > > violated but GP2 is not. > > Not quite. See above. > > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Am Freitag, 3. August 2018 12:09:47 CEST schrieb Jean-Marc Lasgouttes : > Le 3 août 2018 03:44:51 GMT+02:00, ci-...@inria.fr a écrit : > >PASS: tests/test_ExternalTransforms > >PASS: tests/test_ListingsCaption > >FAIL: tests/test_layout > >PASS: tests/test_Length > > Hello, > > The test test_layout is failing. Could someone have a look ? > > JMarc Under ctest, the following tests fail: 68 - check_layout/article-beamer.layout (Failed) 8/6710 Testing: check_layout/article-beamer.layout 68/6710 Test: check_layout/article-beamer.layout Command: "/BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/bin/check_layout" "/usr2/src/lyx/lyx-git/lib/layouts/article-beamer" "/ BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests/article-beamer.outlayout" Directory: /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests "check_layout/article-beamer.layout" start time: Aug 03 18:55 CEST Output: -- LyX: Long string not ended by `EndIsAutoNestedBy' [around line 56 of file current token: '' context: ''] Could not read style NoteItem. 70 - check_layout/beamer.layout (Failed) 70/6710 Testing: check_layout/beamer.layout 70/6710 Test: check_layout/beamer.layout Command: "/BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/bin/check_layout" "/usr2/src/lyx/lyx-git/lib/layouts/beamer" "/ BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests/beamer.outlayout" Directory: /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests "check_layout/beamer.layout" start time: Aug 03 18:55 CEST Output: -- LyX: Long string not ended by `EndIsAutoNestedBy' [around line 56 of file current token: '' context: ''] Could not read style NoteItem. 71 - check_layout/beamerposter.layout (Failed) 71/6710 Test: check_layout/beamerposter.layout Command: "/BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/bin/check_layout" "/usr2/src/lyx/lyx-git/lib/layouts/beamerposter" "/ BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests/beamerposter.outlayout" Directory: /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests "check_layout/beamerposter.layout" start time: Aug 03 18:55 CEST Output: -- LyX: Long string not ended by `EndIsAutoNestedBy' [around line 56 of file current token: '' context: ''] Could not read style NoteItem. 141 - check_layout/scrarticle-beamer.layout (Failed) 141/6710 Test: check_layout/scrarticle-beamer.layout Command: "/BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/bin/check_layout" "/usr2/src/lyx/lyx-git/lib/layouts/scrarticle-beamer" "/BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests/scrarticle-beamer.outlayout" Directory: /BUILD/BUILDMint18/BuildLyxGitQt5.6.1local-gcc5.4.0/src/tests "check_layout/scrarticle-beamer.layout" start time: Aug 03 18:55 CEST Output: -- LyX: Long string not ended by `EndIsAutoNestedBy' [around line 56 of file current token: '' context: ''] Could not read style NoteItem. So it was always the same error. Interestingly the sequence IsAutoNestedBy Itemize,Enumerate EndIsAutoNestedBy looks correct. Kornel signature.asc Description: This is a digitally signed message part.
Re: templates/RJournal.lyx not compilable
On Fri, Aug 03, 2018 at 03:42:14PM +, Jürgen Spitzmüller wrote: > Am Freitag, den 03.08.2018, 11:21 -0400 schrieb Scott Kostyshak: > > Another question that I saw come up is: should the LyX display be the > > same as the PDF output? From what I understand, before the change, > > the > > LyX display was localized to the GUI language, but the LaTeX output > > was > > not localized. Now, both are localized. > > No, the output was also localized before. But the languages were not > correctly marked. Just open an English manual in LyX 2.3 with a German > (or French) UI language. Ah I see. > > In other words, before the > > change, GP2 was violated but GP1 was not. Now it is the opposite: GP1 > > is > > violated but GP2 is not. > > Not quite. See above. Thanks for the correction. Scott signature.asc Description: PGP signature
Re: templates/RJournal.lyx not compilable
Am Freitag, den 03.08.2018, 11:21 -0400 schrieb Scott Kostyshak: > Another question that I saw come up is: should the LyX display be the > same as the PDF output? From what I understand, before the change, > the > LyX display was localized to the GUI language, but the LaTeX output > was > not localized. Now, both are localized. No, the output was also localized before. But the languages were not correctly marked. Just open an English manual in LyX 2.3 with a German (or French) UI language. > In other words, before the > change, GP2 was violated but GP1 was not. Now it is the opposite: GP1 > is > violated but GP2 is not. Not quite. See above. Jürgen signature.asc Description: This is a digitally signed message part
Re: templates/RJournal.lyx not compilable
On Fri, Aug 03, 2018 at 09:51:28AM +, Jürgen Spitzmüller wrote: > Am Freitag, den 03.08.2018, 11:28 +0200 schrieb Kornel Benko: > > Until now we never had this dependency. (Yes, I know this is not a > > nice argument, > > since _we_ want something new) > > The point is: this was a bug. I tried to explain multiple times what > the bug was (wrong hyphenation, encoding errors, etc.), but I will stop > now since this does not seem to reach you. I would like to make an attempt to summarize so that I, and anyone else who would like to, can join this fun debate. I would appreciate it if someone would correct me where I am wrong in the summary. I think we all agree that the following general principles are reasonable in most cases: General Principle 1 (GP1): document output should not depend on preferences, but rather only on document settings. General Principle 2 (GP2): PDF output should reflect [1] the LyX display. I believe (again, please correct me), that the question in this thread is about whether we should make an exception to GP1 for the following case: Suppose that someone who's GUI language is XYZ is reading an example/template/manual document in English, and the document refers to a menu entry (or keyboard shortcut, etc.). We can either output the menu entry in English, or we can output the menu entry in language XYZ. The question is: which should we output? On the one hand, since the user's GUI is in language XYZ, the localized menu entry makes sense (otherwise, the user would have to translate the English string into language XYZ to apply it, which is non-trivial in some cases). On the other hand, if we output language XYZ, we violate GP1. If all of our documents were 100% translated to language XYZ, this problem might not be important, because the user would likely read the document in language XYZ rather than reading it in English. However, most of our documents are not 100% translated, and it is very common for users with non-English GUIs to read English documents. Another question that I saw come up is: should the LyX display be the same as the PDF output? From what I understand, before the change, the LyX display was localized to the GUI language, but the LaTeX output was not localized. Now, both are localized. In other words, before the change, GP2 was violated but GP1 was not. Now it is the opposite: GP1 is violated but GP2 is not. Kornel made a proposal to allow the user to control the tradeoff of violating GP1 versus the convenience of outputting the localized string, either by using a document setting or with a command-line option. I don't see any disagreement with the idea that if the GUI language is used for the menu entry, the LaTeX output should correctly support the language so that e.g. encoding and hyphens are correct. The disagreement is only with the antecedent of that statement [2] (the "if the GUI language is used" part). Please make corrections to the above summary. If the above summary is reasonable, then I suppose we need to debate the value of GP1, or symmetrically the cost of violating it. Why is GP1 important to us? Can we violate it for insets that only LyX developers use, such as info insets? etc. Scott [1] I don't know a better term than "reflects" here, although "reflect" does not feel right. [2] I had to look this word up. I hope I got it correct. signature.asc Description: PGP signature
Installation of Lyx on Windows
Hello A French user tried to install the official lyx-2.3.0 bundle and complained on lyx-fr that no classes were present. I suggested to install MiKTeX first and use the installer instead of the bundle. That was successful. Is this beavior known? -- Jean-Pierre
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1105
Le 3 août 2018 03:44:51 GMT+02:00, ci-...@inria.fr a écrit : >PASS: tests/test_ExternalTransforms >PASS: tests/test_ListingsCaption >FAIL: tests/test_layout >PASS: tests/test_Length Hello, The test test_layout is failing. Could someone have a look ? JMarc
Re: templates/RJournal.lyx not compilable
Am Freitag, 3. August 2018 11:51:28 CEST schrieb Jürgen Spitzmüller : > Am Freitag, den 03.08.2018, 11:28 +0200 schrieb Kornel Benko: > > Until now we never had this dependency. (Yes, I know this is not a > > nice argument, > > since _we_ want something new) > > The point is: this was a bug. I tried to explain multiple times what > the bug was (wrong hyphenation, encoding errors, etc.), Here we agree. > but I will stop > now since this does not seem to reach you. Thanks. But what we have now is a bug too. IMHO. > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: templates/RJournal.lyx not compilable
Am Freitag, den 03.08.2018, 11:28 +0200 schrieb Kornel Benko: > Until now we never had this dependency. (Yes, I know this is not a > nice argument, > since _we_ want something new) The point is: this was a bug. I tried to explain multiple times what the bug was (wrong hyphenation, encoding errors, etc.), but I will stop now since this does not seem to reach you. Jürgen signature.asc Description: This is a digitally signed message part
Re: templates/RJournal.lyx not compilable
Am Freitag, 3. August 2018 11:03:22 CEST schrieb Jürgen Spitzmüller
:
> Am Freitag, den 03.08.2018, 10:13 +0200 schrieb Kornel Benko:
> > I'd prefer the user be able to set the character style of an inset
> > like he wants.
> > So, neither document nor gui language, but the language of
> > surrounding inset.
> > That way every export could be independent of the gui.
>
> But then these insets are useless for our documentation, since it is
> impossible to guess in which localization it will be read. That means
> that the English docs will only be useful for people working with an
> English UI.
The same is valid now if you try to use
lyx -e pdf
As a compromise, we could add a document setting stating that some entries will
be localized in GUI language?
Or, start lyx with an extra option, say -info-inset-lang
> For this, we actually do not need any info insets at all. We can just
> insert static text.
>
> > Not the localization, but the dependence in export behavior is what
> > drives me crazy.
>
> But these are inter-dependent.
Until now we never had this dependency. (Yes, I know this is not a nice
argument,
since _we_ want something new)
...
> > What if you _want_ to describe in your lyx-document these different
> > shortcuts (for different languages)?
>
> This won't work with our current inset info framework anyway.
Yes, but that would be my preference.
> You need to use static text.
And that is error prone against changes in shortcuts ...
> > > Same for French and other languages
> > >
> > > If we do not mark these insets as German, then
> > >
> > > * hyphenation will be wrong
> > > * the spellchecker will yield false positives
> > > * with documents in RTL languages, the text directions will be
> > > wrong
> > > (see #10463)
> > > * with documents in non-latin scripts, compilation will break with
> > > an
> > > encoding error ("Rücktaste" cannot be encoded in Arabic, for
> > > instance).
> > >
> > > Hence we _must_ use the correct language here.
> >
> > Yes, but the GUI language is not right here. IMHO.
>
> Why? It is a _prerequisite_ to prevent the problems mentioned above. So
> if you say "No" to GUI language, you have to say "Yes" to these bugs.
> You cannot have both.
>
> There are only two proper ways here:
>
> * Do not use the UI language at all for these two info insets. This
> means that the info does not match the target if doc and UI language
> differ.
>
> * Properly set the language to UI language on LaTeX output (as we do
> now). This means that the LaTeX output depends on the UI language.
A third way would be the proposed compromise (which I don't like, but feels
less bad)
> I'd prefer the latter, since I think the other option defeats the
> purpose of these insets.
>
> Jürgen
I see, and I am not happy.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: templates/RJournal.lyx not compilable
Am Freitag, den 03.08.2018, 10:13 +0200 schrieb Kornel Benko:
> I'd prefer the user be able to set the character style of an inset
> like he wants.
> So, neither document nor gui language, but the language of
> surrounding inset.
> That way every export could be independent of the gui.
But then these insets are useless for our documentation, since it is
impossible to guess in which localization it will be read. That means
that the English docs will only be useful for people working with an
English UI.
For this, we actually do not need any info insets at all. We can just
insert static text.
> Not the localization, but the dependence in export behavior is what
> drives me crazy.
But these are inter-dependent.
> > * "Ctrl" is localized as "Strg" (which is how German keyboards have
> > it)
> > * "Shift" is localized as "Umschalt"
> > * "Left/Right" are localized as "Links/Rechts"
> > * "Ins" is localized as "Einfg", "Del" as "Entf", "End" as "Ende",
> > etc.
> > * "Backspace" is localized as "Rücktaste"
> > etc.
>
> What if you _want_ to describe in your lyx-document these different
> shortcuts (for different languages)?
This won't work with our current inset info framework anyway. You need
to use static text.
> > Same for French and other languages
> >
> > If we do not mark these insets as German, then
> >
> > * hyphenation will be wrong
> > * the spellchecker will yield false positives
> > * with documents in RTL languages, the text directions will be
> > wrong
> > (see #10463)
> > * with documents in non-latin scripts, compilation will break with
> > an
> > encoding error ("Rücktaste" cannot be encoded in Arabic, for
> > instance).
> >
> > Hence we _must_ use the correct language here.
>
> Yes, but the GUI language is not right here. IMHO.
Why? It is a _prerequisite_ to prevent the problems mentioned above. So
if you say "No" to GUI language, you have to say "Yes" to these bugs.
You cannot have both.
There are only two proper ways here:
* Do not use the UI language at all for these two info insets. This
means that the info does not match the target if doc and UI language
differ.
* Properly set the language to UI language on LaTeX output (as we do
now). This means that the LaTeX output depends on the UI language.
I'd prefer the latter, since I think the other option defeats the
purpose of these insets.
Jürgen
signature.asc
Description: This is a digitally signed message part
Re: templates/RJournal.lyx not compilable
Am Freitag, 3. August 2018 09:37:54 CEST schrieb Jürgen Spitzmüller
:
> Am Donnerstag, den 02.08.2018, 19:52 +0200 schrieb Kornel Benko:
> > Am Donnerstag, 2. August 2018 17:27:02 CEST schrieb Jürgen
> > Spitzmüller :
> > > Am Donnerstag, den 02.08.2018, 16:41 +0200 schrieb Kornel Benko:
> > > > Jürgen, that is _not_ the problem I have with it. In fact, I like
> > > > the
> > > > localized GUI.
> > > > My bad feeling stems from the change in the latex output.
> > >
> > > But this fixes a bug. Previously, the LaTeX output did not use the
> > > correct language.
> >
> > It does not now too.
>
> What do you mean?
See below.
> > This is a valid point. But why should we output GUI language?
> > Even if text is marked in document ( e.g. not GUI) language?
>
> I can only repeat myself: Because these insets refer to the (current
> localized) GUI.
>
> We can discuss whether we should rather use the document (or context)
> language for shortcuts. But then, they won't be localized anymore wrt
> the user's (presumed) keyboard (see below).
I'd prefer the user be able to set the character style of an inset like he
wants.
So, neither document nor gui language, but the language of surrounding inset.
That way every export could be independent of the gui.
> > Back to RJournal.lyx
> >
> > GUI language Slovak.
> > Document language English.
> > Latex output of '2 R code chunks'
> > Press \shortcut{\selectlanguage{slovak}%
> > \inputencoding{latin2}Alt+Z T\selectlanguage{english}%
> > }\inputencoding{latin9} and input R code chunks which will be
> > compiled
> > with the \textbf{knitr} package (\url{http://yihui.name/knitr/}
> > ).
> >
> > Latex output of 'Author A'
> > \address{Author A\\
> > Press \shortcut{\selectlanguage{slovak}%
> > \inputencoding{latin2}Ctrl+Return\selectlanguage{english}%
> > }\inputencoding{latin9} to input\\
> > address here\\
> > \email{author.a@email}}
> >
> > This does not feel right. Sorry.
> >
> > Yes, both are shortcuts, but still, the doc lang is English.
>
> But not the UI language. I think your uncomfortableness stems from the
> fact that the shortcuts doesn't seem to be localized in Slovak and thus
> "look" English. But open the same document in a German UI and notice
> that
Not the localization, but the dependence in export behavior is what drives me
crazy.
> * "Ctrl" is localized as "Strg" (which is how German keyboards have it)
> * "Shift" is localized as "Umschalt"
> * "Left/Right" are localized as "Links/Rechts"
> * "Ins" is localized as "Einfg", "Del" as "Entf", "End" as "Ende", etc.
> * "Backspace" is localized as "Rücktaste"
> etc.
What if you _want_ to describe in your lyx-document these different shortcuts
(for different languages)?
> Same for French and other languages
>
> If we do not mark these insets as German, then
>
> * hyphenation will be wrong
> * the spellchecker will yield false positives
> * with documents in RTL languages, the text directions will be wrong
> (see #10463)
> * with documents in non-latin scripts, compilation will break with an
> encoding error ("Rücktaste" cannot be encoded in Arabic, for instance).
>
> Hence we _must_ use the correct language here.
Yes, but the GUI language is not right here. IMHO.
> > Slowly this conversation starts to feel like a flame war. I don't
> > like it.
> > Should I shut up?
>
> I don't perceive it as a flame war, but rather as a mutual attempt to
> make oneself clear.
OK
> Jürgen
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: templates/RJournal.lyx not compilable
Am Donnerstag, den 02.08.2018, 19:52 +0200 schrieb Kornel Benko:
> Am Donnerstag, 2. August 2018 17:27:02 CEST schrieb Jürgen
> Spitzmüller :
> > Am Donnerstag, den 02.08.2018, 16:41 +0200 schrieb Kornel Benko:
> > > Jürgen, that is _not_ the problem I have with it. In fact, I like
> > > the
> > > localized GUI.
> > > My bad feeling stems from the change in the latex output.
> >
> > But this fixes a bug. Previously, the LaTeX output did not use the
> > correct language.
>
> It does not now too.
What do you mean?
> This is a valid point. But why should we output GUI language?
> Even if text is marked in document ( e.g. not GUI) language?
I can only repeat myself: Because these insets refer to the (current
localized) GUI.
We can discuss whether we should rather use the document (or context)
language for shortcuts. But then, they won't be localized anymore wrt
the user's (presumed) keyboard (see below).
> Back to RJournal.lyx
>
> GUI language Slovak.
> Document language English.
> Latex output of '2 R code chunks'
> Press \shortcut{\selectlanguage{slovak}%
> \inputencoding{latin2}Alt+Z T\selectlanguage{english}%
> }\inputencoding{latin9} and input R code chunks which will be
> compiled
> with the \textbf{knitr} package (\url{http://yihui.name/knitr/}
> ).
>
> Latex output of 'Author A'
> \address{Author A\\
> Press \shortcut{\selectlanguage{slovak}%
> \inputencoding{latin2}Ctrl+Return\selectlanguage{english}%
> }\inputencoding{latin9} to input\\
> address here\\
> \email{author.a@email}}
>
> This does not feel right. Sorry.
>
> Yes, both are shortcuts, but still, the doc lang is English.
But not the UI language. I think your uncomfortableness stems from the
fact that the shortcuts doesn't seem to be localized in Slovak and thus
"look" English. But open the same document in a German UI and notice
that
* "Ctrl" is localized as "Strg" (which is how German keyboards have it)
* "Shift" is localized as "Umschalt"
* "Left/Right" are localized as "Links/Rechts"
* "Ins" is localized as "Einfg", "Del" as "Entf", "End" as "Ende", etc.
* "Backspace" is localized as "Rücktaste"
etc.
Same for French and other languages
If we do not mark these insets as German, then
* hyphenation will be wrong
* the spellchecker will yield false positives
* with documents in RTL languages, the text directions will be wrong
(see #10463)
* with documents in non-latin scripts, compilation will break with an
encoding error ("Rücktaste" cannot be encoded in Arabic, for instance).
Hence we _must_ use the correct language here.
> Slowly this conversation starts to feel like a flame war. I don't
> like it.
> Should I shut up?
I don't perceive it as a flame war, but rather as a mutual attempt to
make oneself clear.
Jürgen
>
> Kornel
>
>
>
>
signature.asc
Description: This is a digitally signed message part
