Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Uwe Stöhr]

Am 21.02.2016 um 18:06 schrieb Uwe Stöhr:


Attached is a patch that adds support for these languages.


The patch is now stored in
http://www.lyx.org/trac/ticket/

It includes also support for Friulan since we could fix friulan-babel.

regards Uwe

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Scott Kostyshak]

On Sun, Feb 28, 2016 at 12:07:13PM +0100, Stephan Witt wrote:

> At the first quick glance I cannot see a problem using it. I’m able to build 
> the
> LyX package and using it. What else should I have a look at?

I would be curious if the Qt 5.6 build magically makes these two issues
go away:

http://www.lyx.org/trac/ticket/9644
http://www.lyx.org/trac/ticket/9992

But I don't think you experience those bugs so we will have to wait
until the reporters can test.

Scott


signature.asc
Description: PGP signature

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Stephan Witt]

Am 28.02.2016 um 15:07 schrieb Enrico Forestieri :
> 
> On Sun, Feb 28, 2016 at 01:37:02PM +0100, Stephan Witt wrote:
> 
>> Am 28.02.2016 um 13:26 schrieb Enrico Forestieri :
>>> 
>>> On Sun, Feb 28, 2016 at 12:07:13PM +0100, Stephan Witt wrote:
 
 I’m able to build Qt 5.6 from source now. I circumvented the compile
 problem by excluding QtTools from the build.
>>> 
>>> It seems that with Qt 5.6.0 you need QtDeclarative for building QtTools.
>> 
>> At the time I failed to build Qt in QtTools I hadn't it excluded.
> 
> It seems that you build from the monolithic sources. Maybe it is a timing
> problem due to parallel building. I find it more convenient compiling
> module by module.

I see. Because of intermediate installation of individual components
it succeeds in the end for you. Probably a missing include directive
in qttools Makefiles...

For LyX packaging the tools are not needed. So I’m happy with the
current state - especially because of the ever increasing size of
the Qt universe.

Any, thank you for the recipe - in case I need it I’ll return to it.

Stephan

> In that way I don't have to exclude anything and if
> something is needed it can be compliled later. This is what I typically do:
> 
> # Build and install Qt5 base
> tar xvf qtbase-opensource-src-5.6.0-rc.tar.xz
> mkdir build; cd build
> ../qtbase-opensource-src-5.6.0-rc/configure -prefix /usr/local/qt/5.6.0 
> -platform linux-g++ -release -opensource -confirm-license -nomake examples
> make -j9
> make install
> 
> # Build and install Qt5 svg module
> tar xvf qtsvg-opensource-src-5.6.0-rc.tar.xz
> mkdir build-svg; cd build-svg
> env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake ../qtsvg-opensource-src-5.6.0-rc
> make -j9
> make install
> 
> # Build and install Qt5 declarative module
> tar xvf qtdeclarative-opensource-src-5.6.0-rc.tar.xz
> mkdir build-decl; cd build-decl
> env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake 
> ../qtdeclarative-opensource-src-5.6.0-rc
> make -j9
> make install
> 
> # Build and install Qt5 tools module
> tar xvf qttools-opensource-src-5.6.0-rc.tar.xz
> mkdir build-tools; cd build-tools
> env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake 
> ../qttools-opensource-src-5.6.0-rc
> make -j9
> make install
> 
> 
> Until Qt 5.5.1 I was simply skipping qtdeclarative, while I got a similar
> compile error with Qt 5.6.0. So, I now simply compile also qtdeclarative
> before qttools.
> 
> -- 
> Enrico

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Enrico Forestieri]

On Sun, Feb 28, 2016 at 01:37:02PM +0100, Stephan Witt wrote:

> Am 28.02.2016 um 13:26 schrieb Enrico Forestieri :
> > 
> > On Sun, Feb 28, 2016 at 12:07:13PM +0100, Stephan Witt wrote:
> >> 
> >> I’m able to build Qt 5.6 from source now. I circumvented the compile
> >> problem by excluding QtTools from the build.
> > 
> > It seems that with Qt 5.6.0 you need QtDeclarative for building QtTools.
> 
> At the time I failed to build Qt in QtTools I hadn't it excluded.

It seems that you build from the monolithic sources. Maybe it is a timing
problem due to parallel building. I find it more convenient compiling
module by module. In that way I don't have to exclude anything and if
something is needed it can be compliled later. This is what I typically do:

# Build and install Qt5 base
tar xvf qtbase-opensource-src-5.6.0-rc.tar.xz
mkdir build; cd build
../qtbase-opensource-src-5.6.0-rc/configure -prefix /usr/local/qt/5.6.0 
-platform linux-g++ -release -opensource -confirm-license -nomake examples
make -j9
make install

# Build and install Qt5 svg module
tar xvf qtsvg-opensource-src-5.6.0-rc.tar.xz
mkdir build-svg; cd build-svg
env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake ../qtsvg-opensource-src-5.6.0-rc
make -j9
make install

# Build and install Qt5 declarative module
tar xvf qtdeclarative-opensource-src-5.6.0-rc.tar.xz
mkdir build-decl; cd build-decl
env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake 
../qtdeclarative-opensource-src-5.6.0-rc
make -j9
make install

# Build and install Qt5 tools module
tar xvf qttools-opensource-src-5.6.0-rc.tar.xz
mkdir build-tools; cd build-tools
env PATH=/usr/local/qt/5.6.0/bin:$PATH qmake ../qttools-opensource-src-5.6.0-rc
make -j9
make install


Until Qt 5.5.1 I was simply skipping qtdeclarative, while I got a similar
compile error with Qt 5.6.0. So, I now simply compile also qtdeclarative
before qttools.

-- 
Enrico

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Kornel Benko]

Am Sonntag, 28. Februar 2016 um 13:33:38, schrieb Enrico Forestieri 

> On Sun, Feb 28, 2016 at 12:19:58PM +0100, Kornel Benko wrote:
> > 
> > Please check the setting/changing of shortcuts.
> > Tools->Preferences->Editing->Shortcuts
> > This does not work with QT5.6 + cmake
> 
> So, what changed for you? Unless I misunderstood, you said that shortcuts
> were working for you but doubled.
> http://thread.gmane.org/gmane.editors.lyx.devel/159882/focus=160181

It was a mistake from my side. The lyx-executable was created with QT5.6, but 
for some reason
at the time of test, the system used QT5.5.1.

Later I rechecked more than once that it does really not work here.
Sorry.

Kornel


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

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Stephan Witt]

Am 28.02.2016 um 13:26 schrieb Enrico Forestieri :
> 
> On Sun, Feb 28, 2016 at 12:07:13PM +0100, Stephan Witt wrote:
>> 
>> I’m able to build Qt 5.6 from source now. I circumvented the compile problem
>> by excluding QtTools from the build.
> 
> It seems that with Qt 5.6.0 you need QtDeclarative for building QtTools.

At the time I failed to build Qt in QtTools I hadn't it excluded.

The compiler error I got was:

...
compiling 
/Users/stephan/git/qt-everywhere-opensource-src-5.6.0-rc/qttools/src/qdoc/main.cpp
In file included from 
/Users/stephan/git/qt-everywhere-opensource-src-5.6.0-rc/qttools/src/qdoc/main.cpp:49:
In file included from 
/Users/stephan/git/qt-everywhere-opensource-src-5.6.0-rc/qttools/src/qdoc/jscodemarker.h:41:
/Users/stephan/git/qt-everywhere-opensource-src-5.6.0-rc/qttools/src/qdoc/qmlcodemarker.h:43:10:
 fatal error: 'private/qqmljsastfwd_p.h' file not found
#include 
 ^
1 error generated.
make[3]: *** [.obj/main.o] Error 1
make[2]: *** [sub-qdoc-make_first] Error 2
make[1]: *** [sub-src-make_first] Error 2
make: *** [module-qttools-make_first] Error 2

The configure command I’ve used is:

$ /Users/stephan/git/qt-everywhere-opensource-src-5.6.0-rc/qtbase/configure 
-top-level -debug-and-release -opensource -silent -shared -confirm-license 
-no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip 
qtconnectivity -skip qtscript -skip qtquickcontrols -prefix 
/Users/Shared/LyX/qt-5.6.0-rc-frameworks-cocoa-x86_64

This is the Qt Open Source Edition.

You are licensed to use this software under the terms of
the Lesser GNU General Public License (LGPL) versions 2.1.
You are also licensed to use this software under the terms of
the GNU Lesser General Public License (LGPL) versions 3.

You have already accepted the terms of the Open Source license.

Preparing build tree...
Running configuration tests (phase 1)...
Done running configuration tests.
Creating qmake...
Done.
Running configuration tests (phase 2)...
Done running configuration tests.

   Configure summary

Build type:macx-clang (x86_64, CPU features: cx16 mmx sse sse2 sse3 ssse3)

Build options:
  Configuration .. accessibility audio-backend avx avx2 build_all c++11 
c++14 c++1z compile_examples concurrent corewlan cups dbus debug 
debug_and_release freetype full-config getaddrinfo getifaddrs gstreamer-1.0 
harfbuzz iconv ipv6ifname large-config largefile medium-config minimal-config 
nis no-pkg-config nostrip opengl pcre png precompile_header qpa qpa 
qt_framework reduce_exports release rpath securetransport shared silent 
small-config sse2 sse3 sse4_1 sse4_2 ssl ssse3 system-zlib 
  Build parts  libs
  Mode ... debug and release; default link: debug
  Using sanitizer(s).. none
  Using C++ standard . c++1z
  Using gold linker... no
  Using new DTAGS  no
  Using PCH .. yes
  Using LTCG . no
  Target compiler supports:
SSE2/SSE3/SSSE3 .. yes/yes/yes
SSE4.1/SSE4.2  yes/yes
AVX/AVX2 . yes/yes

Qt modules and options:
  Qt D-Bus ... yes (loading dbus-1 at runtime)
  Qt Concurrent .. yes
  Qt GUI . yes
  Qt Widgets . yes
  Large File . yes
  QML debugging .. yes
  Use system proxies . no

Support enabled for:
  Accessibility .. yes
  ALSA ... no
  CUPS ... yes
  Evdev .. no
  FontConfig . no
  FreeType ... yes (bundled copy)
  Glib ... no
  GStreamer .. yes (1.0)
  GTK theme .. no
  HarfBuzz ... yes (bundled copy)
  Iconv .. yes
  ICU  no
  Image formats: 
GIF .. yes (plugin, using bundled copy)
JPEG . yes (plugin, using bundled copy)
PNG .. yes (in QtGui, using bundled copy)
  libinput no
  Logging backends: 
journald ... no
syslog   ... no
  mtdev .. no
  Networking: 
CoreWlan . yes
getaddrinfo .. yes
getifaddrs ... yes
IPv6 ifname .. yes
libproxy.. no
OpenSSL .. no
SecureTransport .. yes
  NIS  yes
  OpenGL / OpenVG: 
EGL .. no
OpenGL ... desktop
OpenVG ... no
  PCRE ... yes (bundled copy)
  pkg-config . no 
  PulseAudio . no
  QPA backends: 
DirectFB . no
EGLFS  no
  EGLFS i.MX6  no
  EGLFS i.MX6 Wayland. no
  EGLFS EGLDevice  no
  EGLFS GBM .. no
  EGLFS Mali . no
  EGLFS Raspberry Pi . no
  EGLFS X11 .. no
LinuxFB .. no
Mir client no
XCB .. no
  Session management 

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Enrico Forestieri]

On Sun, Feb 28, 2016 at 12:19:58PM +0100, Kornel Benko wrote:
> 
> Please check the setting/changing of shortcuts.
>   Tools->Preferences->Editing->Shortcuts
> This does not work with QT5.6 + cmake

So, what changed for you? Unless I misunderstood, you said that shortcuts
were working for you but doubled.
http://thread.gmane.org/gmane.editors.lyx.devel/159882/focus=160181

-- 
Enrico

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Enrico Forestieri]

On Sun, Feb 28, 2016 at 12:07:13PM +0100, Stephan Witt wrote:
> 
> I’m able to build Qt 5.6 from source now. I circumvented the compile problem
> by excluding QtTools from the build.

It seems that with Qt 5.6.0 you need QtDeclarative for building QtTools.

-- 
Enrico

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Stephan Witt]

Am 28.02.2016 um 12:19 schrieb Kornel Benko :
> 
> Am Sonntag, 28. Februar 2016 um 12:07:13, schrieb Stephan Witt 
> 
>> Am 24.02.2016 um 15:49 schrieb Stephan Witt :
>>> 
>>> Am 24.02.2016 um 09:57 schrieb Jean-Marc Lasgouttes :
 
 Le 23/02/2016 20:41, Guillaume Munch a écrit :
> Hi Uwe,
> 
> 
> I am offering my own reply since I do not think your messages deserved
> hostile responses.
 
 I am the one to blame here. I apologize for the tone of my answer, which 
 was not warranted. I should have pointed out nicely and calmly that 
 accusing people of soviet-style behavior and disregard for users when 
 getting "no" as an answer is not polite. Instead of that, I answered very 
 aggressively and disqualified myself regarding this argument :-|
 
 I just want to save a snippet from this rant: Uwe and Stephan, could you 
 please report on the state of the new Qt 5.6 RC?
>>> 
>>> I have problems to integrate it in my workflow. I cannot compile it from 
>>> source.
>>> I have to investigate what to do next. Either I can find and fix the 
>>> compile error
>>> (IOW find out how to configure the build to succeed) or I can find out how 
>>> to use
>>> the prebuilt frameworks one can download. :(
>> 
>> I’m able to build Qt 5.6 from source now. I circumvented the compile problem 
>> by
>> excluding QtTools from the build.
>> 
>> At the first quick glance I cannot see a problem using it. I’m able to build 
>> the
>> LyX package and using it. What else should I have a look at?
> 
> Please check the setting/changing of shortcuts.
>   Tools->Preferences->Editing->Shortcuts
> This does not work with QT5.6 + cmake

I can confirm this. It doesn’t work. It doesn't depend on the build tool.

Stephan

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Kornel Benko]

Am Sonntag, 28. Februar 2016 um 12:07:13, schrieb Stephan Witt 
> Am 24.02.2016 um 15:49 schrieb Stephan Witt :
> > 
> > Am 24.02.2016 um 09:57 schrieb Jean-Marc Lasgouttes :
> >> 
> >> Le 23/02/2016 20:41, Guillaume Munch a écrit :
> >>> Hi Uwe,
> >>> 
> >>> 
> >>> I am offering my own reply since I do not think your messages deserved
> >>> hostile responses.
> >> 
> >> I am the one to blame here. I apologize for the tone of my answer, which 
> >> was not warranted. I should have pointed out nicely and calmly that 
> >> accusing people of soviet-style behavior and disregard for users when 
> >> getting "no" as an answer is not polite. Instead of that, I answered very 
> >> aggressively and disqualified myself regarding this argument :-|
> >> 
> >> I just want to save a snippet from this rant: Uwe and Stephan, could you 
> >> please report on the state of the new Qt 5.6 RC?
> > 
> > I have problems to integrate it in my workflow. I cannot compile it from 
> > source.
> > I have to investigate what to do next. Either I can find and fix the 
> > compile error
> > (IOW find out how to configure the build to succeed) or I can find out how 
> > to use
> > the prebuilt frameworks one can download. :(
> 
> I’m able to build Qt 5.6 from source now. I circumvented the compile problem 
> by
> excluding QtTools from the build.
> 
> At the first quick glance I cannot see a problem using it. I’m able to build 
> the
> LyX package and using it. What else should I have a look at?

Please check the setting/changing of shortcuts.
Tools->Preferences->Editing->Shortcuts
This does not work with QT5.6 + cmake

> Stephan

Kornel

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

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Stephan Witt]

Am 24.02.2016 um 15:49 schrieb Stephan Witt :
> 
> Am 24.02.2016 um 09:57 schrieb Jean-Marc Lasgouttes :
>> 
>> Le 23/02/2016 20:41, Guillaume Munch a écrit :
>>> Hi Uwe,
>>> 
>>> 
>>> I am offering my own reply since I do not think your messages deserved
>>> hostile responses.
>> 
>> I am the one to blame here. I apologize for the tone of my answer, which was 
>> not warranted. I should have pointed out nicely and calmly that accusing 
>> people of soviet-style behavior and disregard for users when getting "no" as 
>> an answer is not polite. Instead of that, I answered very aggressively and 
>> disqualified myself regarding this argument :-|
>> 
>> I just want to save a snippet from this rant: Uwe and Stephan, could you 
>> please report on the state of the new Qt 5.6 RC?
> 
> I have problems to integrate it in my workflow. I cannot compile it from 
> source.
> I have to investigate what to do next. Either I can find and fix the compile 
> error
> (IOW find out how to configure the build to succeed) or I can find out how to 
> use
> the prebuilt frameworks one can download. :(

I’m able to build Qt 5.6 from source now. I circumvented the compile problem by
excluding QtTools from the build.

At the first quick glance I cannot see a problem using it. I’m able to build the
LyX package and using it. What else should I have a look at?

Stephan

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Stephan Witt]

Am 24.02.2016 um 09:57 schrieb Jean-Marc Lasgouttes :
> 
> Le 23/02/2016 20:41, Guillaume Munch a écrit :
>> Hi Uwe,
>> 
>> 
>> I am offering my own reply since I do not think your messages deserved
>> hostile responses.
> 
> I am the one to blame here. I apologize for the tone of my answer, which was 
> not warranted. I should have pointed out nicely and calmly that accusing 
> people of soviet-style behavior and disregard for users when getting "no" as 
> an answer is not polite. Instead of that, I answered very aggressively and 
> disqualified myself regarding this argument :-|
> 
> I just want to save a snippet from this rant: Uwe and Stephan, could you 
> please report on the state of the new Qt 5.6 RC?

I have problems to integrate it in my workflow. I cannot compile it from source.
I have to investigate what to do next. Either I can find and fix the compile 
error
(IOW find out how to configure the build to succeed) or I can find out how to 
use
the prebuilt frameworks one can download. :(

Stephan

> I think this will be a good guide for the upcoming release.
> 
> JMarc
> 
> 

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Jean-Marc Lasgouttes]

Le 23/02/2016 20:41, Guillaume Munch a écrit :

Hi Uwe,


I am offering my own reply since I do not think your messages deserved
hostile responses.


I am the one to blame here. I apologize for the tone of my answer, which 
was not warranted. I should have pointed out nicely and calmly that 
accusing people of soviet-style behavior and disregard for users when 
getting "no" as an answer is not polite. Instead of that, I answered 
very aggressively and disqualified myself regarding this argument :-|


I just want to save a snippet from this rant: Uwe and Stephan, could you 
please report on the state of the new Qt 5.6 RC? I think this will be a 
good guide for the upcoming release.


JMarc

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Jean-Marc Lasgouttes]

Le 24/02/2016 09:29, Guenter Milde a écrit :

Actually, it is quite a hard thing to manage languages "by hand", as LyX
automates most of the work. Multilanguage documents would require a babel
call for all languages in the user preamble and ERT for the language
switch.

OTOH, lib/languages can be copied to the user LyXdir and customized, so
experienced or adventurous users do not need to wait 2 years.


Good point. Similarly, we do already accept to add new layouts to 
existing textclasses in stable releases, which is not very different 
from adding new languages. So in theory, we could have a policy of 
adding new languages during stable series.


JMarc

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guenter Milde]

On 2016-02-23, Georg Baum wrote:
> Guillaume Munch wrote:

>> Thank you for your taking time for making these points. So nobody seem
>> to agree that this is as low risk / high reward as Uwe thinks (I cannot
>> judge by myself since I am not familiar with this part of LyX; for
>> instance, I thought that this would provide also spell-checking and
>> support for multi-language documents). Maybe this is the reply that Uwe
>> was looking for.

> Yes, it is a prerequisite for spell checking (you also need dictionaries, I 
> don't know if they exist for these languages). Multilanguage documents can 
> be created with similar workarounds to the ones I mentioned.

Actually, it is quite a hard thing to manage languages "by hand", as LyX
automates most of the work. Multilanguage documents would require a babel
call for all languages in the user preamble and ERT for the language
switch.

OTOH, lib/languages can be copied to the user LyXdir and customized, so
experienced or adventurous users do not need to wait 2 years.

Günter

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 23/02/2016 21:06, Georg Baum a écrit :

Some developers postpone fun stuff because of
the rules and work on boring (but important) bugs instead, others ask for
exceptions for their fun stuff. If these exceptions are made it is quite
likely that those who postponed their work will be upset IMHO.


I know this. Actually that's what I meant when I wrote that I would not
be shocked if an exception was made, that I am in this situation. (Of
course, on the other hand I would not have agreed to delay my "fun"
further). Also, Uwe's patch does not particularly look like fun to me so
I do not suspect him to have fun at the expense of others.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Georg Baum]

Guillaume Munch wrote:

> Thank you for your taking time for making these points. So nobody seem
> to agree that this is as low risk / high reward as Uwe thinks (I cannot
> judge by myself since I am not familiar with this part of LyX; for
> instance, I thought that this would provide also spell-checking and
> support for multi-language documents). Maybe this is the reply that Uwe
> was looking for.

Yes, it is a prerequisite for spell checking (you also need dictionaries, I 
don't know if they exist for these languages). Multilanguage documents can 
be created with similar workarounds to the ones I mentioned.

> However, I still think that Uwe was justified in asking the question. A
> rule allows one to say "no" without having to justify oneself but does
> not preclude exceptions. I find it a bit counter-productive to try to
> justify it now with arguments that are (I find) weak;

Sure, the easiest thing would be to just say no (but I cannot do that, this 
needs to be done by the release manager). Apart from that I do not agree 
that the arguments are weak. Some developers postpone fun stuff because of 
the rules and work on boring (but important) bugs instead, others ask for 
exceptions for their fun stuff. If these exceptions are made it is quite 
likely that those who postponed their work will be upset IMHO.

> for instance #7404
> is nowhere near comparable: it is much more substantial and you targeted
> it to 2.2.x yourself, whereas the 2-year delay was Uwe's most compelling
> argument.

#7404 is actually a very strong argument IMHO: The benefit would be much 
higher than the new languages, but still I removed the 2.2.0 target as soon 
as I realized I would not be able to finish it before the freeze. If we made 
an exception for #7470 we do already know a few users who would be really 
happy. For the new languaes those users do still need to be found.

Maybe my original response reads a bit hard, but this is due to the fact 
that we have had exactly the same discussion for the past few releases, and 
I am really tired of it.


Georg

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Georg Baum]

Uwe Stöhr wrote:

> Am 22.02.2016 um 20:23 schrieb Georg Baum:
> 
>>> Le 21/02/2016 20:52, Scott Kostyshak a écrit :
 On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:
> I also don't see a reason why this cannot be done now since otherwise
> users of than languages would have to wait 2 more years until LyX 2.3.
>>
>> Every LyX release in the past few years was further delayed by
>> last-minute requests like this one. If we stop these last-minute changes,
>> and improve the test coverage we can speed up the release process a lot.
> 
> Time is not important here.

This was meant as an argument against your "2 years". If we agree, we can 
make the time between releases much shorter, so users would not need to wait 
so long if the languages are not in 2.2.0.

> That LyX 2.2 is delayed because Qt 5.6 is still not our and I cannot
> perform my tests annoy me a lot. But that is life and we should use this
> unwanted extra time.

LyX 2.2 is not delayed because of qt. It is delayed because of resource 
limits of the active developers. LyX should be released when it is ready, 
regardless whether qt 5.6 is out or not.

>> Yes. For every new language we need a native speaker to verify that the
>> result is correct. For example, support for urdu was added at
>> http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned
>> out that it was completely unusable, so that it was removed again at
>> http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.
> 
> You forget the other languages added by
> http://www.lyx.org/trac/changeset/7eca5d94/lyxgit that work fine.

I gave an example of a language that did not work. It does not matter for my 
reasoning whether other languages do work. Even languages using latin 
scripts have sometimes special settings (e.g. FontEncoding or special 
preamble code like we have for basque etc). If these settings are wrong it 
might look OK at the first glance, but only a native speaker can tell 
whether it is really OK.

> You are always arguing with rules and I did not even ask for an
> exception. Just focus on the pro and cons.

The rules are not important because of themselves, but there are reasons why 
we have them. For me it follows automatically from these reasons that we 
should stick to the rules in general. I always make the mistake to assume 
that the reasons for the rules are well known. This is does not seem to be 
the case, but Jean-Marc has explained the reasons quite well.


Georg

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Hi Uwe,


I am offering my own reply since I do not think your messages deserved 
hostile responses.



Le 22/02/2016 23:40, Uwe Stöhr a écrit :

Am 22.02.2016 um 20:23 schrieb Georg Baum:


Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.


Every LyX release in the past few years was further delayed by
last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.


Time is not important here. The question is if adding a feature makes
sense. This change is of low risk but opens LyX for a wider audience.
Ergo a big plus for the marketing. There is also nothing specially to
test and nothing that can be broken. (all are LTR languages with either
Latin or Cyrillic script). So the question is not the time a patch is
sent but its benefit.
I cannot speak any of the languages of my patch so it would not help me
personally. I see the obvious benefit and not yet a technical reason
against this. As my goal is to spread LyX it makes sense to support as
many languages as possible.



Thank you for this effort. As I gather, developers find it too risky
anyway at this stage of development.





Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned
out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.


You forget the other languages added by
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit that work fine.
Take for example Hindi. This language was enabled with this patch and
people are using this (2 downloads a week of the dictionary for LyX). So
do you reapply prefer to wait until a native speaker gives his OK? Then
LyX would still not support Hindi. At first we need to attract users. If
e.g. a Macedonian user find a problem he will report it. If we don't
provide language support, we will most probably never have a Macedonian
LyX user.
Just for interest Bosnian is almost the same as Serbocroatian (the
language discussion in BiH is quite ridiculous, but OK as long as they
have peace, every party gets his "language".)


I am convinced by the details you gave; obviously you made your research 
before proposing this patch. However Georg more generally made the point 
that language support should be tested by a native speaker, which I 
would tend to agree, and obviously it is too late for that now.



Guillaume

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 22/02/2016 19:23, Georg Baum a écrit :

Guillaume Munch wrote:


Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.


Every LyX release in the past few years was further delayed by last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.

Besides that, every LyX release misses some features that are important for
some users. The only way to avoid this is to throw a massive amount of
developer man power upon LyX, and we all know that this won't happen.


I agree that this is unfortunate. But the same is true for any feature.
The feature freeze was over two months ago. Now we are focusing only on
bug fixes. I do not think it would be fair to make an exception for this
patch.


Exactly. Such exceptions punish those who play by the rules and reward those
who ignore the rules. This does not mean that I don't like the support for
the new languages. It is a very good thing to have, just not right now.


I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.


Because they have not been proposed. I have several easy features or bug
fixes I'd like to put in (e.g. http://www.lyx.org/trac/ticket/7404), but I
did not propose them after the freeze because I assumed that the freeze was
a freeze. Instead, I used my time for reviewing needed changes, and for
fixing show stopper bugs.


* Is the lack of these languages easy to work around if the patch is
postponed?


Yes. Load babel manually in the preamble, and disable the automatic loading
via preferences (language settings->language package=none)


* Is there any risk that the settings might be wrong (especially in ways
that cannot be fixed without another file format increase)?


Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.





Thank you for your taking time for making these points. So nobody seem
to agree that this is as low risk / high reward as Uwe thinks (I cannot
judge by myself since I am not familiar with this part of LyX; for
instance, I thought that this would provide also spell-checking and
support for multi-language documents). Maybe this is the reply that Uwe
was looking for.

However, I still think that Uwe was justified in asking the question. A
rule allows one to say "no" without having to justify oneself but does
not preclude exceptions. I find it a bit counter-productive to try to
justify it now with arguments that are (I find) weak; for instance #7404
is nowhere near comparable: it is much more substantial and you targeted
it to 2.2.x yourself, whereas the 2-year delay was Uwe's most compelling
argument.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 23/02/2016 01:51, Pavel Sanda a écrit :

Guillaume Munch wrote:

I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.


String changes break finalized translations or harass workflow for people
who work on them meanwhile... P



Yes, obviously we don't want to change the strings. Otherwise I would 
have already implemented that little checkbox to switch 
\save_transient_properties. I did not realize it did.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Jean-Marc Lasgouttes]

Le 23/02/2016 00:40, Uwe Stöhr a écrit :

Time is not important here. The question is if adding a feature makes
sense. This change is of low risk but opens LyX for a wider audience.
Ergo a big plus for the marketing.

That LyX 2.2 is delayed because Qt 5.6 is still not our and I cannot
perform my tests annoy me a lot. But that is life and we should use this
unwanted extra time.


You keep telling us how professional we should be. Do you think that 
professional programmer make up new features in feature freeze? No they 
don't. I have a todo file of about 20 things I am going to do (some 
trivial some hard) when tree is open again. Instead of being just 
frustrated, I used the time to research those things. And you say we 
don't care if it takes longer? Thanks.


Concerning Qt 5.6, it is supposed to be out on March 3, so that's OK wrt 
our release plans. But RC has been released just today. What we should 
be doing, especially with platforms that plan to use that for release, 
is to download it, test, report bugs, fix them. Not invent new tasks.


But then there are our users. What is more important in your eyes? 
Delivering Bosnian to 0.01% of our user base, or giving proper Retina on 
Mac OS as fast as we can? I don't do marketing, but I am sure you have 
an answer.


And there is the language issue too. If we ever manage to release 2.2 
because it is complete enough, it will make Thai usable, speed up 
rendering in Arabic and Hebrew, make Chinese editing practical. Is it 
something worth enough in your eyes to admit that maybe "time is important"?


Yes, two years is too long between releases. But the answer is not to 
make it 2 years and a half to add a handful of features that have not 
made it yet because. Release time is not fun, it requires discipline. 
The earliest we are done with it, the best.



That Urdu and Syriac did not work well has to do with RTL support. Btw.,
JMarc, what is the status of this, Could Urdu now be supported?


Yes, but you should have asked this question 6 months ago. LaTeX support 
is slightly different from other languages, so someone who cares has to 
take the time to implement it. I did my part, but there is more to do. I 
did not have any answer when I pinged our Urdu user, so I moved on.



You are always arguing with rules and I did not even ask for an
exception. Just focus on the pro and cons.


This sums it up pretty well :(

JMarc

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Pavel Sanda]

Guillaume Munch wrote:
> I would not be shocked if an exception was made. Uwe's point is that it
> is low risk/high reward and that being delayed until 2.3 is quite
> significant. I do not remember seeing another patch in this situation.

String changes break finalized translations or harass workflow for people
who work on them meanwhile... P

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Uwe Stöhr]

Am 22.02.2016 um 20:23 schrieb Georg Baum:


Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.


Every LyX release in the past few years was further delayed by last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.


Time is not important here. The question is if adding a feature makes 
sense. This change is of low risk but opens LyX for a wider audience. 
Ergo a big plus for the marketing. There is also nothing specially to 
test and nothing that can be broken. (all are LTR languages with either 
Latin or Cyrillic script). So the question is not the time a patch is 
sent but its benefit.
I cannot speak any of the languages of my patch so it would not help me 
personally. I see the obvious benefit and not yet a technical reason 
against this. As my goal is to spread LyX it makes sense to support as 
many languages as possible.


That LyX 2.2 is delayed because Qt 5.6 is still not our and I cannot 
perform my tests annoy me a lot. But that is life and we should use this 
unwanted extra time.



Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.


You forget the other languages added by 
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit that work fine.
Take for example Hindi. This language was enabled with this patch and 
people are using this (2 downloads a week of the dictionary for LyX). So 
do you reapply prefer to wait until a native speaker gives his OK? Then 
LyX would still not support Hindi. At first we need to attract users. If 
e.g. a Macedonian user find a problem he will report it. If we don't 
provide language support, we will most probably never have a Macedonian 
LyX user.
Just for interest Bosnian is almost the same as Serbocroatian (the 
language discussion in BiH is quite ridiculous, but OK as long as they 
have peace, every party gets his "language".)


That Urdu and Syriac did not work well has to do with RTL support. Btw., 
JMarc, what is the status of this, Could Urdu now be supported?


> Exactly. Such exceptions punish those who play by the rules and 
reward those

> who ignore the rules.

You are always arguing with rules and I did not even ask for an 
exception. Just focus on the pro and cons.


> This does not mean that I don't like the support for the new 
languages. It is a very good thing to have, just not right now.


So we are waiting another e.g. 2 years because a rule is more important? 
That reminds me of my Cuba trip where they have the rule that there are 
only 4 buses a day connecting the 2 biggest cities of the country. No 
matter if there are suddenly more people than for 4 buses, rule is rule 
(planned economy). Not nice if you are affected! In the rest of the 
world they would just organize some extra buses. They would be happy to 
get more money and you would be happy about the service. As you can see 
rules are a nice framework but one has to makes decisions for every 
certain cases despite the rules.



regards Uwe

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Georg Baum]

Guillaume Munch wrote:

> Le 21/02/2016 20:52, Scott Kostyshak a écrit :
>> On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:
>>> I also don't see a reason why this cannot be done now since otherwise
>>> users of than languages would have to wait 2 more years until LyX 2.3.

Every LyX release in the past few years was further delayed by last-minute 
requests like this one. If we stop these last-minute changes, and improve 
the test coverage we can speed up the release process a lot.

Besides that, every LyX release misses some features that are important for 
some users. The only way to avoid this is to throw a massive amount of 
developer man power upon LyX, and we all know that this won't happen.

>> I agree that this is unfortunate. But the same is true for any feature.
>> The feature freeze was over two months ago. Now we are focusing only on
>> bug fixes. I do not think it would be fair to make an exception for this
>> patch.

Exactly. Such exceptions punish those who play by the rules and reward those 
who ignore the rules. This does not mean that I don't like the support for 
the new languages. It is a very good thing to have, just not right now.

> I would not be shocked if an exception was made. Uwe's point is that it
> is low risk/high reward and that being delayed until 2.3 is quite
> significant. I do not remember seeing another patch in this situation.

Because they have not been proposed. I have several easy features or bug 
fixes I'd like to put in (e.g. http://www.lyx.org/trac/ticket/7404), but I 
did not propose them after the freeze because I assumed that the freeze was 
a freeze. Instead, I used my time for reviewing needed changes, and for 
fixing show stopper bugs.

> * Is the lack of these languages easy to work around if the patch is
> postponed?

Yes. Load babel manually in the preamble, and disable the automatic loading 
via preferences (language settings->language package=none)

> * Is there any risk that the settings might be wrong (especially in ways
> that cannot be fixed without another file format increase)?

Yes. For every new language we need a native speaker to verify that the 
result is correct. For example, support for urdu was added at 
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out 
that it was completely unusable, so that it was removed again at 
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit. 


Georg

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise users of
than languages would have to wait 2 more years until LyX 2.3.


I agree that this is unfortunate. But the same is true for any feature.
The feature freeze was over two months ago. Now we are focusing only on
bug fixes. I do not think it would be fair to make an exception for this
patch.


I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.

* Is the lack of these languages easy to work around if the patch is
postponed?

* Is there any risk that the settings might be wrong (especially in ways
that cannot be fixed without another file format increase)?





(The patch misses of course the necessary update of the fileformat of all
*.lyx files to keep the patch readable.)


I've been thinking about the best way to handle this. Perhaps the best
way is to update only the necessary test files with the patch you post,
and then update the rest of the files in a separate patch (that you
either post or don't).

It would be nice to be able to apply your patch and have the tex2lyx
tests still pass. What do others think is the best way?



I have been making the routine updates in separate commits (also helps 
for rebasing), and sending all the patches given by git format-patch. 
Clearer this way. Just make sure that the patches are ordered properly 
and that the boring ones come last.



Guillaume

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Scott Kostyshak]

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:
> While advertising LyX to a business colleague I was asked if it can handle
> Macedonian. I was surprised that we don't support it yet and had a closer
> look.

I am surprised too, given the other languages that LyX already supports.

> In fact Macedonian and Bosnian are official languages and babel supports
> them for years (also in TeXLive).
> 
> I also encountered that Piedmontese and Romansh are supported by babel and
> polyglossia and their support is in TeXLive 2015 (and probably in earlier
> versions too).

It is fun to read and learn about these languages. Piedmontese is
actually spoken by over a million people. And can anyone guess what the
fourth official language of Switzerland is? It's Romansh! This is good
to remember for the next pub quiz :)

> Attached is a patch that adds support for these languages.
> Yes, this would be a fileformat change, but in my opinion it is worth it: By
> supporting 2 languages that are official ones we can attract more user.

Thanks for your work on this. It is great to bring LyX to more users and
to support even more languages.

> I also don't see a reason why this cannot be done now since otherwise users of
> than languages would have to wait 2 more years until LyX 2.3.

I agree that this is unfortunate. But the same is true for any feature.
The feature freeze was over two months ago. Now we are focusing only on
bug fixes. I do not think it would be fair to make an exception for this
patch.

> OK to go in?

Regarding 2.3.0, will your business colleague be able to test LyX's
support for Macedonian with your patch? I don't actually care whether
he/she tests before or after you commit, but it would be great to get
feedback from someone who actually knows and uses the language.

> (The patch misses of course the necessary update of the fileformat of all
> *.lyx files to keep the patch readable.)

I've been thinking about the best way to handle this. Perhaps the best
way is to update only the necessary test files with the patch you post,
and then update the rest of the files in a separate patch (that you
either post or don't).

It would be nice to be able to apply your patch and have the tex2lyx
tests still pass. What do others think is the best way?

Scott


signature.asc
Description: PGP signature

[patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Uwe Stöhr]

While advertising LyX to a business colleague I was asked if it can 
handle Macedonian. I was surprised that we don't support it yet and had 
a closer look.


In fact Macedonian and Bosnian are official languages and babel supports 
them for years (also in TeXLive).


I also encountered that Piedmontese and Romansh are supported by babel 
and polyglossia and their support is in TeXLive 2015 (and probably in 
earlier versions too).


Attached is a patch that adds support for these languages.
Yes, this would be a fileformat change, but in my opinion it is worth 
it: By supporting 2 languages that are official ones we can attract more 
user. I also don't see a reason why this cannot be done now since 
otherwise users of than languages would have to wait 2 more years until 
LyX 2.3.


OK to go in?

(The patch misses of course the necessary update of the fileformat of 
all *.lyx files to keep the patch readable.)


many thanks and regards
Uwe
 development/FORMAT |  7 +
 lib/languages  | 51 +++
 lib/lyx2lyx/LyX.py |  2 +-
 lib/lyx2lyx/lyx_2_2.py | 81 +-
 src/version.h  |  4 +--
 5 files changed, 141 insertions(+), 4 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index 1d24d92..8ffc1e0 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,13 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
 
 ---
 
+2016-02-21 Uwe Stöhr 
+   * Format incremented to 507: support for Bosnian, Macedonian, 
Piedmontese and Romansh:
+ \lang bosnian
+ \lang macedonian
+ \lang piedmontese
+ \lang romansh
+
 2016-01-26 Guillaume Munch 
* Format incremented to 506
  No new parameters.
diff --git a/lib/languages b/lib/languages
index d56d030..c188f56 100644
--- a/lib/languages
+++ b/lib/languages
@@ -285,6 +285,15 @@ Language british
LangCode en_GB
 End
 
+# not yet supported by polyglossia
+Language bosnian
+   GuiName  "Bosnian"
+   BabelNamebosnian
+   QuoteStyle   polish
+   Encoding iso8859-2
+   LangCode bs_BA
+End
+
 Language bulgarian
GuiName  "Bulgarian"
BabelNamebulgarian
@@ -480,6 +489,18 @@ Language french
EndPostBabelPreamble
 End
 
+# A bug prevents curently the output. If this is fixed, this can be enabled.
+# Would be a fileformat change!
+#Language friulan
+#  GuiName  "Friulian"
+#  HasGuiSupporttrue
+#  BabelNamefriulan
+#  PolyglossiaName  friulan
+#  QuoteStyle   french
+#  Encoding iso8859-15
+#  LangCode fur_IT
+#End
+
 Language galician
GuiName  "Galician"
HasGuiSupporttrue
@@ -758,6 +779,16 @@ Language lowersorbian
LangCode dsb_DE
 End
 
+# not yet supported by polyglossia
+Language macedonian
+   GuiName  "Macedonian"
+   BabelNamemacedonian
+   QuoteStyle   german
+   Encoding cp1251
+   FontEncoding T2A
+   LangCode mk_MK
+End
+
 Language magyar
GuiName  "Hungarian"
HasGuiSupporttrue
@@ -837,6 +868,16 @@ End
 #  LangCode ru_petr1708
 # End
 
+Language piedmontese
+   GuiName  "Piedmontese"
+   HasGuiSupporttrue
+   BabelNamepiedmontese
+   PolyglossiaName  piedmontese
+   QuoteStyle   french
+   Encoding iso8859-15
+   LangCode pms_IT
+End
+
 Language polish
GuiName  "Polish"
HasGuiSupporttrue
@@ -868,6 +909,16 @@ Language romanian
LangCode ro_RO
 End
 
+Language romansh
+   GuiName  "Romansh"
+   HasGuiSupporttrue
+   BabelNameromansh
+   PolyglossiaName  romansh
+   QuoteStyle   german
+   Encoding iso8859-15
+   LangCode rm_CH
+End
+
 Language russian
GuiName  "Russian"
HasGuiSupporttrue
diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
index b2b5731..e7078f1 100644
--- a/lib/lyx2lyx/LyX.py
+++ b/lib/lyx2lyx/LyX.py
@@ -86,7 +86,7 @@ format_relation = [("0_06",[200], minor_versions("0.6" , 
4)),
("1_6", list(range(277,346)), minor_versions("1.6" , 10)),
("2_0", list(range(346,414)), minor_versions("2.0" , 8)),
("2_1", list(range(414,475)), minor_versions("2.1" , 0)),
-   ("2_2", list(range(475,507)), minor_versions("2.2" , 0))
+   ("2_2", list(range(475,508)), minor_versions("2.2" , 0))
   ]
 
 
diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index a1f3005..5b668da 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@