Am Freitag, 3. August 2018 11:03:22 CEST schrieb Jürgen Spitzmüller <sp...@lyx.org>: > 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.
