Re: templates/RJournal.lyx not compilable

2018-08-03 Thread Kornel Benko
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: templates/RJournal.lyx not compilable

2018-08-03 Thread Scott Kostyshak
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

2018-08-03 Thread 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. 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

2018-08-03 Thread Scott Kostyshak
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


Re: templates/RJournal.lyx not compilable

2018-08-03 Thread Kornel Benko
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

2018-08-03 Thread 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.), 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

2018-08-03 Thread Kornel Benko
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

2018-08-03 Thread 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.

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

2018-08-03 Thread Kornel Benko
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

2018-08-03 Thread 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?

> 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


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread 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.

> Why should we output German text, for example, marked
> as English? This is simply wrong.
> 
> Jürgen
> 

This is a valid point. But why should we output GUI language?
Even if text is marked in document ( e.g. not GUI) language?

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.

Slowly this conversation starts to feel like a flame war. I don't like it.
Should I shut up?

Kornel






signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread 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. Why should we output German text, for example, marked
as English? This is simply wrong.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Kornel Benko
Am Donnerstag, 2. August 2018 16:25:20 CEST schrieb Jürgen Spitzmüller 
:
> Am Donnerstag, den 02.08.2018, 11:45 +0200 schrieb Kornel Benko:
> > So, if I want to output the English version of a document I have to
> > change my GUI language to English?
> > This does not make sense, probably only for me of course.
> 
> It is only for two info insets: menu and shortcut. Their purpose is to
> show you the menu entry/shortcut in your current GUI. So if you use a
> German GUI, it should say "Bearbeiten > Einfügen", not "Edit > Paste".
> Else you won't find it.
> 
> Jürgen

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.

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.08.2018, 11:58 +0200 schrieb Kornel Benko:
> Next try to make myself clear.
> 
> Go to the end of this document (GUI is German ATM)
> Select the last inset (Author B ...), change the language of the
> inset to Slovak, look at the created latex
> 
> % Quellcode für Absatz 14 vorschauen
> 
> \selectlanguage{slovak}%
> 
> \address{\inputencoding{latin2}Author B\\
> \email{\selectlanguage{english}%
> \inputencoding{latin9}author.b@email\selectlanguage{slovak}%
> }}\selectlanguage{english}%
> 
> What is the meaning of '\email{\selectlanguage{english}%' now?

It switches back to English I suppose.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.08.2018, 11:45 +0200 schrieb Kornel Benko:
> So, if I want to output the English version of a document I have to
> change my GUI language to English?
> This does not make sense, probably only for me of course.

It is only for two info insets: menu and shortcut. Their purpose is to
show you the menu entry/shortcut in your current GUI. So if you use a
German GUI, it should say "Bearbeiten > Einfügen", not "Edit > Paste".
Else you won't find it.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Kornel Benko
Am Donnerstag, 2. August 2018 11:45:59 CEST schrieb Kornel Benko 
:
> Am Donnerstag, 2. August 2018 10:12:17 CEST schrieb Jürgen Spitzmüller 
> :
> > Am Donnerstag, den 02.08.2018, 09:05 +0200 schrieb Kornel Benko:
> > > Unfortunately nowadays some insets are given GUI-language, 
> > 
> > Two corrections: 
> > 1. This has always been the case, only it has not been considered in
> > LaTeX output, which gave the errors I mentioned in a previous message.
> > 2. This is not unfortunate, but by design. An englisch menu entry with
> > a German UI just would not make sense. Likewise an English Shortcut.
> > 
> > Jürgen
> > 
> 
> So, if I want to output the English version of a document I have to change my 
> GUI language to English?
> This does not make sense, probably only for me of course.
> 
>   Kornel
> 

Next try to make myself clear.

Go to the end of this document (GUI is German ATM)
Select the last inset (Author B ...), change the language of the inset to 
Slovak, look at the created latex

% Quellcode für Absatz 14 vorschauen

\selectlanguage{slovak}%

\address{\inputencoding{latin2}Author B\\
\email{\selectlanguage{english}%
\inputencoding{latin9}author.b@email\selectlanguage{slovak}%
}}\selectlanguage{english}%

What is the meaning of '\email{\selectlanguage{english}%' now?

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Kornel Benko
Am Donnerstag, 2. August 2018 10:12:17 CEST schrieb Jürgen Spitzmüller 
:
> Am Donnerstag, den 02.08.2018, 09:05 +0200 schrieb Kornel Benko:
> > Unfortunately nowadays some insets are given GUI-language, 
> 
> Two corrections: 
> 1. This has always been the case, only it has not been considered in
> LaTeX output, which gave the errors I mentioned in a previous message.
> 2. This is not unfortunate, but by design. An englisch menu entry with
> a German UI just would not make sense. Likewise an English Shortcut.
> 
> Jürgen
> 

So, if I want to output the English version of a document I have to change my 
GUI language to English?
This does not make sense, probably only for me of course.

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Jürgen Spitzmüller
Am Donnerstag, den 02.08.2018, 09:05 +0200 schrieb Kornel Benko:
> Unfortunately nowadays some insets are given GUI-language, 

Two corrections: 
1. This has always been the case, only it has not been considered in
LaTeX output, which gave the errors I mentioned in a previous message.
2. This is not unfortunate, but by design. An englisch menu entry with
a German UI just would not make sense. Likewise an English Shortcut.

Jürgen


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-02 Thread Kornel Benko
Am Mittwoch, 1. August 2018 17:03:22 CEST schrieb Kornel Benko :
> Am Mittwoch, 1. August 2018 16:53:19 CEST schrieb Jürgen Spitzmüller 
> :
> > Am Mittwoch, den 01.08.2018, 16:44 +0200 schrieb Kornel Benko:
> > > Does not help if set in .layout.
> > > 
> > > Setting  Language Package to "Default" in the document works, but
> > > only without 'Provides babel 1'
> > 
> > Local Layouts and .layout should be equivalent. Maybe you have a layout
> > in your local (~./lyx) directory that is used instead of the one you
> > edited?
> > 
> > Jürgen
> 
> No, I don't have. And yes, I know how to use Local Layouts.
> 
> For tests, I am using the lyx-executable in the build-dir, so that
> the system-dir is in the lyx-repo.
> 

Unfortunately nowadays some insets are given GUI-language, so that the 
latex-export
of a document changes. To see this
1.) Select GUI to, say German
2.) Restart lyx (important)
3.) Open templates/RJournal.lyx
4.) export to LaTeX(pdflatex) and rename  RJournal.tex to RJournal.get.tex
5.) Select GUI to english
6.) Restart lyx
7.) export to LaTeX(pdflatex) and rename  RJournal.tex to RJournal.us.tex
8.) Compare the two exported tex files
(diff attached)

Kornel
--- RJournal.ger.tex	2018-08-02 08:57:55.114279952 +0200
+++ RJournal.us.tex	2018-08-02 08:32:23.977247669 +0200
@@ -64,7 +64,7 @@
 
 \section{R code chunks}
 
-Press \shortcut{\selectlanguage{ngerman}%
+Press \shortcut{\selectlanguage{american}%
 Alt+Z T\selectlanguage{english}%
 } and input R code chunks which will be compiled with the \textbf{knitr}
 package (\url{http://yihui.name/knitr/}).
@@ -109,8 +109,8 @@
 
 
 \address{Author A\\
-Press \shortcut{\selectlanguage{ngerman}%
-Strg+Return\selectlanguage{english}%
+Press \shortcut{\selectlanguage{american}%
+Ctrl+Return\selectlanguage{english}%
 } to input\\
 address here\\
 \email{author.a@email}}


signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Kornel Benko
Am Mittwoch, 1. August 2018 16:53:19 CEST schrieb Jürgen Spitzmüller 
:
> Am Mittwoch, den 01.08.2018, 16:44 +0200 schrieb Kornel Benko:
> > Does not help if set in .layout.
> > 
> > Setting  Language Package to "Default" in the document works, but
> > only without 'Provides babel 1'
> 
> Local Layouts and .layout should be equivalent. Maybe you have a layout
> in your local (~./lyx) directory that is used instead of the one you
> edited?
> 
> Jürgen

No, I don't have. And yes, I know how to use Local Layouts.

For tests, I am using the lyx-executable in the build-dir, so that
the system-dir is in the lyx-repo.

Kornel



signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Jürgen Spitzmüller
Am Mittwoch, den 01.08.2018, 16:44 +0200 schrieb Kornel Benko:
> Does not help if set in .layout.
> 
> Setting  Language Package to "Default" in the document works, but
> only without 'Provides babel 1'

Local Layouts and .layout should be equivalent. Maybe you have a layout
in your local (~./lyx) directory that is used instead of the one you
edited?

Jürgen


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Kornel Benko
Am Mittwoch, 1. August 2018 15:48:33 CEST schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 29.07.2018, 20:48 +0200 schrieb Jürgen Spitzmüller:
> > Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> > > Hm, not as easy here, since that file has "no language package".
> > > Have to think about that.
> > 
> > It's actually the problem you already reported some time ago: we need
> > to output global language options even if babel is provided or even
> > not
> > used (if only for packages that inherit these options).
> 
> This issue is now fixed. In the RJournal.lyx file itself, you now need
> to set Language Package to "Default". If the package loads babal itself
> (I cannot test that), you need to set 
> Provides babel 1
> either in the template or the layout.

Does not help if set in .layout.

Setting  Language Package to "Default" in the document works, but only without 
'Provides babel 1'

> Jürgen

I'd like to change the layout only, but didn't figure out what settings to use.

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Jürgen Spitzmüller
Am Sonntag, den 29.07.2018, 20:48 +0200 schrieb Jürgen Spitzmüller:
> Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> > Hm, not as easy here, since that file has "no language package".
> > Have to think about that.
> 
> It's actually the problem you already reported some time ago: we need
> to output global language options even if babel is provided or even
> not
> used (if only for packages that inherit these options).

This issue is now fixed. In the RJournal.lyx file itself, you now need
to set Language Package to "Default". If the package loads babal itself
(I cannot test that), you need to set 
Provides babel 1
either in the template or the layout.

Jürgen




signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Jürgen Spitzmüller
Am Mittwoch, den 01.08.2018, 08:57 +0200 schrieb Kornel Benko:
> This was different.

No, it's ultimately the same bug (global language list not output if
babel is provided by the class).

> In case of RJournal, the GUI language was Slovak, and that should
> have no impact
> on the compilation.

Not if you use menu or shortcut info insets (the latter is the case for
this file). These use the GUI language (since the need to represent the
current GUI), and we must also use this language in the output.
Otherwise hyphenation will be wrong for menu entries, and you even get
LaTeX errors with non-latin scripts.

Jürgen


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Kornel Benko
Am Mittwoch, 1. August 2018 08:36:41 CEST schrieb Jürgen Spitzmüller 
:
> Am Mittwoch, den 01.08.2018, 08:20 +0200 schrieb Kornel Benko:
> > Am Sonntag, 29. Juli 2018 20:48:30 CEST schrieb Jürgen Spitzmüller <
> > sp...@lyx.org>:
> > > Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> > > > Hm, not as easy here, since that file has "no language package".
> > > > Have to think about that.
> > > 
> > > It's actually the problem you already reported some time ago:
> > 
> > Can not remember.
> 
> It was in PM, RE: "Babel Frage".

This was different.
In case of RJournal, the GUI language was Slovak, and that should have no impact
on the compilation.
In case of sr-vorl it was the document language

> > > we need
> > > to output global language options even if babel is provided or even
> > > not
> > > used (if only for packages that inherit these options).
> > > 
> > > Jürgen
> > > 
> > 
> > Mark, that with lyx2.3 there are no problems.
> 
> Sure, the insetinfo fixes are not yet backported.
> 
> > As it is now, it feels like a regression.
> 
> Please be patient. I'll fix it if I find the time.

Thanks.

> Jürgen
> 

Kornel



signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Jürgen Spitzmüller
Am Mittwoch, den 01.08.2018, 08:20 +0200 schrieb Kornel Benko:
> Am Sonntag, 29. Juli 2018 20:48:30 CEST schrieb Jürgen Spitzmüller <
> sp...@lyx.org>:
> > Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> > > Hm, not as easy here, since that file has "no language package".
> > > Have to think about that.
> > 
> > It's actually the problem you already reported some time ago:
> 
> Can not remember.

It was in PM, RE: "Babel Frage".

> > we need
> > to output global language options even if babel is provided or even
> > not
> > used (if only for packages that inherit these options).
> > 
> > Jürgen
> > 
> 
> Mark, that with lyx2.3 there are no problems.

Sure, the insetinfo fixes are not yet backported.

> As it is now, it feels like a regression.

Please be patient. I'll fix it if I find the time.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-08-01 Thread Kornel Benko
Am Sonntag, 29. Juli 2018 20:48:30 CEST schrieb Jürgen Spitzmüller 
:
> Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> > Hm, not as easy here, since that file has "no language package".
> > Have to think about that.
> 
> It's actually the problem you already reported some time ago:

Can not remember.

> we need
> to output global language options even if babel is provided or even not
> used (if only for packages that inherit these options).
> 
> Jürgen
> 

Mark, that with lyx2.3 there are no problems.

As it is now, it feels like a regression.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: templates/RJournal.lyx not compilable

2018-07-29 Thread Jürgen Spitzmüller
Am Sonntag, den 29.07.2018, 20:11 +0200 schrieb Jürgen Spitzmüller:
> Hm, not as easy here, since that file has "no language package".
> Have to think about that.

It's actually the problem you already reported some time ago: we need
to output global language options even if babel is provided or even not
used (if only for packages that inherit these options).

Jürgen

> 
> Jürgen
> 
> > 
> > Jürgen
> > 
> > > 
> > >   Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-07-29 Thread Jürgen Spitzmüller
Am Sonntag, den 29.07.2018, 19:52 +0200 schrieb Jürgen Spitzmüller:
> Am Sonntag, den 29.07.2018, 19:15 +0200 schrieb Kornel Benko:
> > Latest lyx-version.
> > ! Package babel Error: Unknown language `slovak'. Either you
> > have
> > (babel)misspelled its name, it has not been
> > installed,
> > (babel)or you requested it in a previous run.
> > Fix its name,
> > (babel)install it or just rerun the file,
> > respectively. In
> > (babel)some cases, you may need to remove the
> > aux file.
> > 
> > This is not correct, because only the lyx-GUI is Slovak, not the
> > content of RJournal.lyx
> 
> This is due to 803a88f243120. The shortcut and menu info insets now
> (correctly) use the GUI language, but this is not loaded.
> 
> I'll have a look.

Hm, not as easy here, since that file has "no language package".
Have to think about that.

Jürgen

> 
> Jürgen
> 
> > 
> > Kornel


signature.asc
Description: This is a digitally signed message part


Re: templates/RJournal.lyx not compilable

2018-07-29 Thread Jürgen Spitzmüller
Am Sonntag, den 29.07.2018, 19:15 +0200 schrieb Kornel Benko:
> Latest lyx-version.
>   ! Package babel Error: Unknown language `slovak'. Either you
> have
>   (babel)misspelled its name, it has not been
> installed,
>   (babel)or you requested it in a previous run.
> Fix its name,
>   (babel)install it or just rerun the file,
> respectively. In
>   (babel)some cases, you may need to remove the
> aux file.
> 
> This is not correct, because only the lyx-GUI is Slovak, not the
> content of RJournal.lyx

This is due to 803a88f243120. The shortcut and menu info insets now
(correctly) use the GUI language, but this is not loaded.

I'll have a look.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part