Re: UTF-8 in string literals and translation strings in particular

[Guillaume Munch]

Please, do not scatter the messages that much, and make the discussion
easy to follow.


Recalling the subject of the discussion:


Le 08/10/2015 01:55, Cyrille Artho a écrit :


Why not apply a variant of that hack as using "sed" to all the
language/menu strings in the repository? Of course the changes would
 have to be checked by a human in case one wants to keep "..." in
some cases.


I already did these replacements in the previously posted patch. The
issue is that we then need to adapt the translation chain to be
compatible with UTF-8 strings in the source and ensure that all goes
well. This is also done in the patch. I took the time to make these
improvements because I see them as a lifting of restrictions for future
creative improvements to the UI (for which my patch may or may not
suffice, but this is a first step).

Pavel and Jean-Marc have technical objections that they haven't always
made very clear yet, they are also worried that it might increase the
work of the translators, and Jean-Marc and Abdel suggest alternatives
which are more hackish than my solution.



1. About technical objections


Le 07/10/2015 00:23, Pavel Sanda a écrit :

To clarify, I'm not against having ellipsis in the menu per se by
whatever mechanism you use to pass it to Qt routines. What I am not
way too happy is increasing % of utf8-based source code itself and
following translations.



But, encouraging to use UTF-8 is the main purpose of the patch, and you
are not providing further arguments.

I would have understood a reluctance about UTF-8 five years ago, but
it is not likely to go away now that it is here. Moreover having sources
in this specific encoding is becoming common practice, for instance it
is even a requirement for Qt5 compatibility:
.

Here's a short example of symbols that cannot be used yet in translation
strings, default menu .inc files, and translatable parts of
layouts/modules, and which we have to hack to get them anywhere else:

“ ” ° § ¶ ½ µ ÷ ✓ £ ␣ ‰


Le 07/10/2015 10:14, Jean-Marc Lasgouttes a écrit :


I would not describe that code as readable ;) This early return in
the loop is pretty weird.



I wanted to leave the algorithm unchanged on the ASCII subset, because I
feared that somebody would find to object about a possible loss in
performance. I knew I had to think about everything to get this patch
accepted. Now I can simply say that I will write the simpler,
non-optimised version instead if you prefer. I doubt that
there would be any perceptible difference.






(For ellipses though, I find more useful to read … in the source
rather than \u2026.)


Well it would if our mechanism for sending patches to lyx-cvs did
specify correctly the attachment encoding to utf8. Right now, I just
see garbage.



This is a separate issue that will need to be fixed, but there is no
time pressure. If that becomes too inconvenient then it means that the
patch that I propose has become useful. Also, are you sure that the
problem is with the mechanism that you mention? I also have issues with
the encoding of attached files, but after investigating the headers I
concluded that it was a bug in Thunderbird.




2. About translations and translators



Le 07/10/2015 09:36, Jean-Marc Lasgouttes a écrit :

Le 06/10/2015 21:43, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Well, actually I am not sure that we use the same ellipsis as in
 English.


You mean as a translator I need to find French version of
ellipsis?


I am not sure that it exists.



Jean-Marc's joke ironically shows that we should use Unicode, because if
there was such a convention in France around a different shape of the
ellipsis symbol, then OpenType fonts could provide it as a localised
variant through the feature called 'locl' and it would be taken care of
by e.g. Pango/HarfBuzz (under Linux), not LyX. (This is food for
orthotypographic thoughs.)

But I think that in the rest of the discussion we have already agreed
that we would ideally like to have … in the menus.




On 07/10/2015 10:54, Jean-Marc Lasgouttes wrote:

By doing this change, we put more pressure on our translators to do
thing right.


Which I would rather call "showing the good example", and which is good
as long as it does not incur more work for translators.


So I wanted to see if it was as simple as I thought, and solve the
problem at once with a small script that changes ... into …  in the po
files whenever the source string has changed in this way. (It takes as a
source both translations before and after message merge). Also, when one
is certain about the translation (i.e. up to this substitution it
matches exactly a former non-fuzzy translation), one must remove the
"fuzzy" tag or this might confuse translators.

I have to give you credit for your reluctance because I have found that
the string suggested by gettext was not always the good one. But I have
also found that in these 

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 08/10/2015 11:58, Guillaume Munch a écrit :

Please, do not scatter the messages that much, and make the discussion
easy to follow.


I will reply only to some of the arguments for the sake of efficiency.


Le 07/10/2015 00:23, Pavel Sanda a écrit :

To clarify, I'm not against having ellipsis in the menu per se by
whatever mechanism you use to pass it to Qt routines. What I am not
way too happy is increasing % of utf8-based source code itself and
following translations.



But, encouraging to use UTF-8 is the main purpose of the patch, and you
are not providing further arguments.


The problem with the patch is that it does not have a clear goal. The 
discussion would have been much easier if you had splitted it in 3 from 
the start:


1/ easy use of utf8 in docstring
2/ allow utf8 in translattable strings
3/ use … instead of ... in UI

And now we have to discuss it all in one 'for or  against my proposal' 
discussion.


For the record, concerning these 3 problems:
1/ I would agree with extending docstring so that it considers that char 
const * and std::string represent UTF8. However, I wonder what is the 
best approach for that. Making this work only for some operators seems 
strange to me. Wouldn't it be possible to set up some implicit constructors?


2/ This is possible, as long as we prove that their is a need for it. I 
know/think that gettext discourages use of non-ascii, but I do not know 
whether there are valid reasons for that.


3/ I agree that we should use … in UI, but I have reservations about 
whether changing all of our po files is the way to go right now.



I would have understood a reluctance about UTF-8 five years ago, but
it is not likely to go away now that it is here. Moreover having sources
in this specific encoding is becoming common practice, for instance it
is even a requirement for Qt5 compatibility:
.


We do already specify utf8 for our source (comments actually).


I would not describe that code as readable ;) This early return in
the loop is pretty weird.


I wanted to leave the algorithm unchanged on the ASCII subset, because I
feared that somebody would find to object about a possible loss in
performance. I knew I had to think about everything to get this patch
accepted. Now I can simply say that I will write the simpler,
non-optimised version instead if you prefer. I doubt that
there would be any perceptible difference.


OK.


Well it would if our mechanism for sending patches to lyx-cvs did
specify correctly the attachment encoding to utf8. Right now, I just
see garbage.



This is a separate issue that will need to be fixed, but there is no
time pressure. If that becomes too inconvenient then it means that the
patch that I propose has become useful. Also, are you sure that the
problem is with the mechanism that you mention? I also have issues with
the encoding of attached files, but after investigating the headers I
concluded that it was a bug in Thunderbird.


I agree that it is a separate issue.


I am not sure that it exists.


Jean-Marc's joke ironically shows that we should use Unicode, because if
there was such a convention in France around a different shape of the
ellipsis symbol, then OpenType fonts could provide it as a localised
variant through the feature called 'locl' and it would be taken care of
by e.g. Pango/HarfBuzz (under Linux), not LyX. (This is food for
orthotypographic thoughs.)


Does it mean that the font looks different when I change the language of 
the document? Why not.



The script gives by construction no false positive (i.e. we remove the
fuzzy tag only when we are sure), and it provides a diagnosis, so we can
check that there are very few false negatives (I haven't seen one yet)
(this means that there is always a reason to let a fuzzy translation go
to the translators). I would propose to run it right after the 2.2
string merge and right before they are given to translators.


That is reasonable if we go this way.


Our translateors are not all geeks. We have to make life easy for
them.


I did not realise that this particular discussion was about how
*translators* will type the special characters. Because for translators
the solution is pretty simple: it's copy and paste.


You mean that one is supposed for reach for the mouse just to type 
something? Not the fastest way to go. But we could possibly provide 
guidance for each language.


Seriously, saying "use your mouse to get it" or "type Alt 2 0 2 6 every 
time you want to get the character" is taking people a bit lightly.
The idea of LyX is to walk the fine line between canonical LaTeX and 
convenience. Likewise, we should consider where the line is between 
strict orthotypography and convenience.



An alternative would be the attached hack.


But, I still do not see how you want to treat my enhancement for
HSpaceUi.ui with that kind of hack. (And, you call it a hack yourself.)


Don't use 

Re: UTF-8 in string literals and translation strings in particular

[Stephan Witt]

Am 08.10.2015 um 16:02 schrieb Jean-Marc Lasgouttes :

>>> I have to admit that I did not understand Abdel's idea %-|
>> 
>> I understood it that way: to present the ellipsis character in the UI
>> there is no need to put that character with unicode in the source code.
>> It is possible to translate the sequence "..." to the character "…"
>> within the I18N process. I think the po files were not in the scope
>> of this discussion - they don't count as "source" files here.
> 
> Then it is exactly what my "hack" does. I attach it again for reference.

I think the idea was to let the translators do it manually where it is
appropriate. And to do it for english this way too.

Stephan

> It probably needs a bit more polish, but the idea is here.
> 
> JMarc
> 
> <0001-Transform-.-to-proper-ellipsis-in-translations.patch>

Fwd: Some buttons on Maths palette don't work!

[Stephan Witt]

This is really interesting.

LyX 2.2.0 fixes some problem on latest Mac OS "El Capitan".
I guess the fix is there because of the change to Qt5.

We should start with the release process of the thing, IMHO.

Stephan

Anfang der weitergeleiteten Nachricht:

> Von: jken...@ssc.wisc.edu
> Betreff: Aw: Some buttons on Maths palette don't work!
> Datum: 8. Oktober 2015 14:56:25 MESZ
> An: "Stephan Witt" 
> Kopie: "John Kennan" 
> 
> Stephan:
> 
> Thanks for sending this. I tried it on El Capitan, and it fixes the
> problem with the math palette.
> 
> And again, thanks for LyX.
> 
> John
> 
>> Am 08.10.2015 um 03:23 schrieb John Kennan :
>> 
>>> 
>>> The palette problem on El Capitan doesn't seem to have anything to
>>> do with SIP -- I disabled it (and reconfigured LyX) and the problem
>>> remained. This is LyX 2.1.4 (on a Retina machine -- the same LyX on
>>> a different Retina machine running OS X 10.10.5 doesn't have this
>>> problem). If there was a test version of 2.2 available for OSX, I
>>> could try that.
>> 
>> Hi John,
>> 
>> 2 or 3 weeks ago I've placed a disk image and a signature file with
>> the LyX 2.2.0 developer version here:
>> 

…

>> You may try it. Open the disk image and copy the LyX app to your
>> desktop or so.
>> 
>> On first start it will copy your preferences from LyX 2.1 to a
>> separate 2.2 directory. All changes to the preferences you'll make
>> afterwards are independent from your LyX 2.1 settings. These are the
>> good news. Your documents will be converted to the new (and not
>> stable) file format LyX 2.2 is using. Your LyX 2.1 will not be able to
>> open them after saving with 2.2!!! This is the bad one. Be careful.
>> 
>> I'm very interested to hear if this works better on El Capitan. The
>> biggest difference regarding on screen rendering is the newer Qt
>> version used by LyX.
>> 
>> Regards,
>> Stephan
>> 
>>> 
>>> Actually, I can't get any of the Greek symbols by clicking on the
>>> palette.
>>> 
>>> --
>>> John Kennan
>> 
> 
> 

Re: UTF-8 in string literals and translation strings in particular

[Stephan Witt]

Am 08.10.2015 um 15:45 schrieb Jean-Marc Lasgouttes :

> Le 08/10/2015 11:58, Guillaume Munch a écrit :
>> Please, do not scatter the messages that much, and make the discussion
>> easy to follow.
> 
> I will reply only to some of the arguments for the sake of efficiency.
> 

…

> 
>> Le 07/10/2015 20:32, Abdelrazak Younes a écrit :
>>> 
>>> No need for any hack: Another alternative that works AFAIR and is
>>> cleaner IMO, english to english translation works. So, for english or
>>> french actually, ... can be translated to the ellipsis character.
> 
> I have to admit that I did not understand Abdel's idea %-|

I understood it that way: to present the ellipsis character in the UI
there is no need to put that character with unicode in the source code.
It is possible to translate the sequence "..." to the character "…"
within the I18N process. I think the po files were not in the scope
of this discussion - they don't count as "source" files here.

Stephan

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

I have to admit that I did not understand Abdel's idea %-|


I understood it that way: to present the ellipsis character in the UI
there is no need to put that character with unicode in the source code.
It is possible to translate the sequence "..." to the character "…"
within the I18N process. I think the po files were not in the scope
of this discussion - they don't count as "source" files here.


Then it is exactly what my "hack" does. I attach it again for reference. 
It probably needs a bit more polish, but the idea is here.


JMarc

>From c48e487a7c1ba98061d55d6b2d0f2b2a0a219986 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 7 Oct 2015 10:34:06 +0200
Subject: [PATCH] Transform ... to proper ellipsis in translations

---
 src/support/Messages.cpp |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/support/Messages.cpp b/src/support/Messages.cpp
index da1c3cc..177436f 100644
--- a/src/support/Messages.cpp
+++ b/src/support/Messages.cpp
@@ -94,6 +94,7 @@
 #endif
 
 using namespace std;
+using namespace lyx::support;
 using boost::uint32_t;
 
 namespace lyx {
@@ -125,6 +126,10 @@ void cleanTranslation(docstring & trans)
}
break;
}
+
+   static docstring const threedots = from_ascii("...");
+   static docstring const ellipsis = docstring(1, 0x2026);
+   trans = subst(trans, threedots, ellipsis);
 }
 
 } // lyx
@@ -132,8 +137,6 @@ void cleanTranslation(docstring & trans)
 
 #ifdef ENABLE_NLS
 
-using namespace lyx::support;
-
 namespace lyx {
 
 std::string Messages::gui_lang_;
-- 
1.7.9.5

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

[PhilipPirrip]

Dear Guillaume,
I finished my search for the bug yesterday, by checking out a few 
suspicious commits in the last 30 days, and to my great surprise even 
the latest commit worked. I really don't know what happened. I had it 
all built in a separate directory (that I even cleaned several times), 
git status was OK etc.
I'm so sorry for the noise. But I'm sure the advice people gave me will 
help someone backtrace the problems.




On 10/08/2015 09:39 AM, Guillaume Munch wrote:

Dear Philip,

I cannot reproduce it with my own documents. Have you managed to get a
backtrace? Or maybe I could try again with yours if you send me the
documents that LyX loads automatically on your side? (if not too private)

Best regards,
Guillaume

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

[Guillaume Munch]

Le 06/10/2015 15:41, PhilipPirrip a écrit :

Thanks, Kornel. I'll check these later. I went back in time, September
28 18:13 commit 39343d65af worked. Moving forward, will let you know
when things went bad and send you the backtrace.




Dear Philip,

I cannot reproduce it with my own documents. Have you managed to get a 
backtrace? Or maybe I could try again with yours if you send me the 
documents that LyX loads automatically on your side? (if not too private)


Best regards,
Guillaume

Re: LyX on high resolution displays

[PhilipPirrip]

On 09/13/2015 09:39 PM, Scott Kostyshak wrote:

Here's a screenshot:
>http://wiki.lyx.org/uploads/Playground/LyX_screenshot_HiDPI_13inch_display_3200x1800_2015-09-13_Qt5.png



Ouch that indeed does not look good. I feel like this is a Qt bug.
Unless our .ui files are not well-defined, Qt is responsible for the
dialog elements not running into each other.



Dear Scott, now that you're the release manager: how likely is it that 
the layout of the widgets in Document>Settings and Tools>Preferences 
will be fixed for v2.2, some of the sheets look really bad... so crumpled.
This is mostly with the widgets that are grouped within 
class="QGroupBox",they go too high into the title.
The other widgets are also packed very tightly in these settings 
dialogs, regardles of the screen resolution (it just becomes more 
obvious on HiDPI). This should be a cosmetic change, I tried it in Qt 
designer and things looked better, but I feel it needs a retouch from 
someone who's more experienced.
I can help along the way, even change these things with some guidance. 
But can it happen for 2.2?




One other thing:
I think that "Huge-sized" icons should be 40, or even 42 px in size 
(instead of just 32, that feels like 16 or less on normal dpi displays). 
Is there a way of knowing that the screen is HiDPI? Could a factor of 2 
be introduced with the old icon sizes so that the user doesn't need to 
intervene. (also, we should consider what happens when one switches from 
a HiDPI to a normal screen using these huge icons)


This is in frontends/qt4/GuiView.cpp

Re: UTF-8 in string literals and translation strings in particular

[Kornel Benko]

Am Donnerstag, 8. Oktober 2015 um 16:14:49, schrieb Stephan Witt 

> Am 08.10.2015 um 16:02 schrieb Jean-Marc Lasgouttes :
> 
> >>> I have to admit that I did not understand Abdel's idea %-|
> >> 
> >> I understood it that way: to present the ellipsis character in the UI
> >> there is no need to put that character with unicode in the source code.
> >> It is possible to translate the sequence "..." to the character "…"
> >> within the I18N process. I think the po files were not in the scope
> >> of this discussion - they don't count as "source" files here.
> > 
> > Then it is exactly what my "hack" does. I attach it again for reference.
> 
> I think the idea was to let the translators do it manually where it is
> appropriate. And to do it for english this way too.

I think that too. I did it for sk.po, it looks OK to me.
No change in UI or source. Nobody is forced to change the po files. Encouraging
to do so is OK IMHO.

> Stephan
> 
> > It probably needs a bit more polish, but the idea is here.
> > 
> > JMarc
> > 
> > <0001-Transform-.-to-proper-ellipsis-in-translations.patch>

Kornel

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

Lyx fundamental problem in interpreting new document classes?

[Weijie Chen]

Dear LYX Developers,


I want to draw your attention to two questions posted on stackoverflow. I think 
they are similar/related. I wonder if this is a fundamental Lyx limit or the 
end users have not used Lyx properly. Your help is greatly appreciated.


http://stackoverflow.com/questions/33001341/lyx-missing-abstract-in-output-for-sage-journal-article

[http://cdn.sstatic.net/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded]

Lyx missing abstract in output for sage journal article
I've successfully added a document class called "article (sagej)" into Lyx 
using the .cls file found at 
https://uk.sagepub.com/sites/default/files/sage_latex_template_0.zip However, I 
have two i...
Read 
more...




http://stackoverflow.com/questions/29476394/lyx-title-abstract-keywords-missing-when-using-elsevier-class-in-view?rq=1

[http://cdn.sstatic.net/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded]

LyX -- Title, Abstract, Keywords Missing When Using Elsevier Class in View
I'm pretty new to using LyX, but have looked around this forum, as well as 
others and haven't found anyone else who has encountered this problem. The 
issue is that, when I click on the 'eyes' to p...
Read 
more...

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

[Guillaume Munch]

Le 08/10/2015 15:27, PhilipPirrip a écrit :

Dear Guillaume,
I finished my search for the bug yesterday, by checking out a few
suspicious commits in the last 30 days, and to my great surprise even
the latest commit worked. I really don't know what happened. I had it
all built in a separate directory (that I even cleaned several times),
git status was OK etc.
I'm so sorry for the noise. But I'm sure the advice people gave me will
help someone backtrace the problems.



This is no noise. I recently had a segfault as well with up-to-date 
master and I wasn't able to reproduce it, I was hoping that we could 
find it thanks to you. But I'm glad to read that it's fine now.

Re: UTF-8 in string literals and translation strings in particular

[Guillaume Munch]

Le 08/10/2015 16:46, Kornel Benko a écrit :

Am Donnerstag, 8. Oktober 2015 um 16:14:49, schrieb Stephan Witt



I think the idea was to let the translators do it manually where
it is appropriate. And to do it for english this way too.


I think that too. I did it for sk.po, it looks OK to me. No change
in UI or source. Nobody is forced to change the po files. Encouraging
to do so is OK IMHO.



With this approach, Jean-Marc's objections suddenly become meaningful:



You mean that one is supposed for reach for the mouse just to type
something? Not the fastest way to go. But we could possibly provide
guidance for each language.

Seriously, saying "use your mouse to get it" or "type Alt 2 0 2 6
every time you want to get the character" is taking people a bit
lightly. The idea of LyX is to walk the fine line between canonical
LaTeX and convenience. Likewise, we should consider where the line
is between strict orthotypography and convenience.


I could always update fr.po by hand to have ellipses as you suggest, but 
will future translators do it when new cases arise, if the original 
string does not even give the good example and if one has to 
remember/look elsewhere to get this special char?


This approach is fundamentally broken. The sed script that replaces "" 
with “” was only a workaround for the same problem we are discussing now.



Guillaume

Re: UTF-8 in string literals and translation strings in particular

[Guillaume Munch]

Le 08/10/2015 14:45, Jean-Marc Lasgouttes a écrit :

I will reply only to some of the arguments for the sake of
efficiency.


As we usually say, I lacked the time to make it shorter...



The problem with the patch is that it does not have a clear goal.
The discussion would have been much easier if you had splitted it in
3 from the start:

1/ easy use of utf8 in docstring 2/ allow utf8 in translattable
strings 3/ use … instead of ... in UI


I planned to do that eventually. I have started being less eager in my
rebases after a gentle remark from Richard, but this was after I started
working on this patch. Not today, though.



And now we have to discuss it all in one 'for or  against my
proposal' discussion.


Please discuss 2), for which 1) and 3) are an immediate consequence to
me. This was also what I raised in my original message as witnessed by
the subject of the thread. Indeed I do not think 1) or 3) alone would be
quite worth our time.



For the record, concerning these 3 problems: 1/ I would agree with
extending docstring so that it considers that char const * and
std::string represent UTF8. However, I wonder what is the best
approach for that. Making this work only for some operators seems
strange to me. Wouldn't it be possible to set up some implicit
constructors?


My rationale was that UTF-8 strings are only intermediates for building
docstrings or QStrings, on which we do the real operations. Operating on
strings directly must still be discouraged. So nothing changes here, it
is just a bit easier to build docstrings with non-ASCII chars. We do not
want more operations on strings. Or did I miss any obvious operation we 
want?




2/ This is possible, as long as we prove that their is a need for
it.


How do we proceed? We have provided several examples already.


I know/think that gettext discourages use of non-ascii, but I do not
know whether there are valid reasons for that.


I could not find post-2004 sources about this. Gettext supports UTF-8 
starting from version 0.12 and we now have a proof of concept that it 
works for LyX.





Does it mean that the font looks different when I change the
language of the document? Why not.


Yes, it's already a thing in some languages.




I did not realise that this particular discussion was about how
*translators* will type the special characters. Because for
translators the solution is pretty simple: it's copy and paste.


You mean that one is supposed for reach for the mouse just to type
something? Not the fastest way to go. But we could possibly provide
guidance for each language.

Seriously, saying "use your mouse to get it" or "type Alt 2 0 2 6
every time you want to get the character" is taking people a bit
lightly. The idea of LyX is to walk the fine line between canonical
LaTeX and convenience. Likewise, we should consider where the line
is between strict orthotypography and convenience.



What I mean is, if I am translating fr.po, I get the following:

  #: src/frontends/qt4/ui/HSpaceUi.ui:37
  msgid "…… (dots)"
  msgstr ""

and now I just have to copy-paste the dots:

  msgstr "…… (pointillés)"

I do not see why you refer to the idea of LyX in this context or speak
of grabbing the mouse. I don't understand the confusion. Are you
thinking of the manuals? But I am not suggesting changes to the manuals.
LaTeX's ellipsis is quite different and I do not like it just like you 
don't.




3/ I agree that we should use … in UI, but I have reservations about
whether changing all of our po files is the way to go right now.


The script gives by construction no false positive (i.e. we remove
the fuzzy tag only when we are sure), and it provides a diagnosis,
so we can check that there are very few false negatives (I haven't
seen one yet) (this means that there is always a reason to let a
fuzzy translation go to the translators). I would propose to run
it right after the 2.2 string merge and right before they are given
to translators.


That is reasonable if we go this way.





An alternative would be the attached hack.


But, I still do not see how you want to treat my enhancement for
HSpaceUi.ui with that kind of hack. (And, you call it a hack
yourself.)


Don't use my words against me :) It is a hack because I wrote it in
10 minutes and I would not put that in code before checking what is
missing. Since it operates are message translation time (not only
menus), I would say that it does 95% of the work.



95% is approximately the concrete figure I have for my own script, and
the rest only has to be corrected/validated only once by hand in a 
distributed fashion ;)





A contributor has to do a first step, unless your "not for today"
is a euphemism for never.


Be my guest! I do not think that anybody coming up with support for
STIX fonts would be turned down.


I meant, I consider that improving LyX's support for Unicode at the UI
level is a first step towards anything Unicode.




Le 07/10/2015 20:32, Abdelrazak Younes a écrit :


No need for 

Re: UTF-8 in string literals and translation strings in particular

[Kornel Benko]

Am Donnerstag, 8. Oktober 2015 um 17:35:46, schrieb Guillaume Munch 

> Le 08/10/2015 16:46, Kornel Benko a écrit :
> > Am Donnerstag, 8. Oktober 2015 um 16:14:49, schrieb Stephan Witt
> > 
> >>
> >> I think the idea was to let the translators do it manually where
> >> it is appropriate. And to do it for english this way too.
> >
> > I think that too. I did it for sk.po, it looks OK to me. No change
> > in UI or source. Nobody is forced to change the po files. Encouraging
> > to do so is OK IMHO.
> 
> 
> With this approach, Jean-Marc's objections suddenly become meaningful:
> 
> 
> > You mean that one is supposed for reach for the mouse just to type
> > something? Not the fastest way to go. But we could possibly provide
> > guidance for each language.
> >
> > Seriously, saying "use your mouse to get it" or "type Alt 2 0 2 6
> > every time you want to get the character" is taking people a bit
> > lightly. The idea of LyX is to walk the fine line between canonical
> > LaTeX and convenience. Likewise, we should consider where the line
> > is between strict orthotypography and convenience.
> 
> I could always update fr.po by hand to have ellipses as you suggest, but 
> will future translators do it when new cases arise, if the original 
> string does not even give the good example and if one has to 
> remember/look elsewhere to get this special char?

Makes sense.

> This approach is fundamentally broken. The sed script that replaces "" 
> with “” was only a workaround for the same problem we are discussing now.
> 

True.

> Guillaume

Kornel

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

Re: Release manager for LyX 2.2

[Georg Baum]

Pavel Sanda wrote:

> Hi all,
> 
> it is very clear that we need to move forward with the release process.
> 
> After the discussion with the former and current managers we agreed that
> Scott Kostyshak has our trust for the role of release manager of 2.2. He
> has good understanding of the code and is constantly around to help with
> the development process which makes him a perfect candidate.
> 
> He tentatively agreed to accept such responsibility.
> 
> If someone has objections to this proposal please speak now or never :)
> Otherwise I wish good luck to our new release manager!

Me too! And many thanks to Scott for volunteering, this is really great 
news.


Georg

Re: Release manager for LyX 2.2

[Enrico Forestieri]

On Wed, Oct 07, 2015 at 11:08:21AM +0200, Jean-Marc Lasgouttes wrote:
> Le 07/10/2015 11:04, Pavel Sanda a écrit :
> >Hi all,
> >
> >it is very clear that we need to move forward with the release process.
> >
> >After the discussion with the former and current managers we agreed that 
> >Scott
> >Kostyshak has our trust for the role of release manager of 2.2. He has good
> >understanding of the code and is constantly around to help with the 
> >development
> >process which makes him a perfect candidate.
> >
> >He tentatively agreed to accept such responsibility.
> >
> >If someone has objections to this proposal please speak now or never :)
> >Otherwise I wish good luck to our new release manager!
> 
> That is very good news. Scott, welcome to your new role.

ACK

> Besides checking everything that may go wrong, remember that the second most
> important part of the job is to say "no"! And that's not the easiest part.

Out of curiosity, what French typography dictates for a punctuation sign
after a double quote? Shouldn't it be inside the quotes? 8-)

-- 
Enrico

Re: LyX on high resolution displays

[Georg Baum]

Guillaume Munch wrote:

> Hi,
> 
> 
> Note that under Linux+Qt5, there's this bug:
> 
> http://www.lyx.org/trac/ticket/9731
> 
> presumably fixed in Qt5.6:
> 
> https://codereview.qt-project.org/#/c/126136/
> 
> 1) Is your testing environment still Linux?
> 2) Does the slowness disappear if you scroll with arrow keys or
> PageUp/Down instead of the touchpad?
> 3) Does the bug go away if you compile with Qt5.6?

HDPI was a hot topic at the qt world summit this week. I did not attend any 
talk about it, but what I heard is that qt 5.6 is supposed to be much 
better. I'd recommend anyone working on this to try 5.6 and have a look at 
the slides of the talks "High-dpi Qt" and "How to Develop with Qt for 
Multiple Screen Resolutions and Increase & Measure your Cross-Platform App 
Success (In-Depth Tech Session)" when they become available at 
qtworldsummit.com.


Georg

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Georg Baum]

David Hyde wrote:

> Hi there,
> 
> 
> I'm interested in compiling LyX on Windows.  I've read through the
> INSTALL.Win32 file and was able to get LyX to compile from source using
> Visual C++ Express 2010, following the instructions in that file.

Great!

> I'm
> wondering though, is it possible (do people have experience, or know it
> doesn't work, etc.) to compile LyX using a more recent VS version (2013 or
> even 2015)?  VS2010 isn't supported very well anymore (it was hard to even
> find a download for VS2010), so being able to compile LyX on Windows using
> more modern toolchains would be very useful.

This is possible, but needs some work. Currently we are lacking a volunteer 
to do it. If you are interested (which would be much appreciated) we can 
help by answering any questions that might come up.

The current MSVC build instructions use some pre-compiled third party 
libraries. Of course these work only for exactly one MSVC version. Therefore 
I would propose the following procedure instead of just replicating this 
setup with a newer MSVC version:

Create a python or cmake script that downloads, unpacks and builds each 
needed library. Add this script to the LyX git repo, and modify the windows 
cmake setup to use it instead of the current binaries from sourceforge.

This is more initial work, but definitely worth it, because it has a very 
high probability that it works with future MSVC versions as well.


Georg

Re: UTF-8 in string literals and translation strings in particular

[Enrico Forestieri]

On Thu, Oct 08, 2015 at 09:48:52PM +0200, Jean-Marc Lasgouttes wrote:
> Le 08/10/15 03:19, Cyrille Artho a écrit :
> >It's possible to embed characters from a font in an SVG graph; this
> >could be used to avoid problems with fonts that do not have all math
> >characters.
> 
> I seem to remember (but git log is your friend) that these icon started
> their life with embedded fonts, and that they were transformed to something
> else later.
> 
> But only Enrico can tell us what the status is.

I don't think they were embedded as they looked different on different
platforms. They were replaced with paths, i.e., a vectorial representation
of the used characters, so that they appear the same on any platform as
they were originally intended. This can be done with inkscape: after
inserting some text using a specific font, it can be transformed into a
path by a menu entry.

-- 
Enrico

Re: UTF-8 in string literals and translation strings in particular

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> The problem with the patch is that it does not have a clear goal. The
> discussion would have been much easier if you had splitted it in 3 from
> the start:
> 
> 1/ easy use of utf8 in docstring
> 2/ allow utf8 in translattable strings
> 3/ use … instead of ... in UI

4) use of unicode string literals in C++ source files

This would have been easier indeed. For example, I have no real opinion 
about 2) and 3).

4) is not possible as long as we support C++98 (because the source encoding 
is not standardized and especially MSVC has a horrible interpretation of 
it).

Concerning 1) I have a strong opinion which needs a bit of history 
explained: When unicode support was introduced in LyX the idea was to 
replace all strings which can contain non-ASCII contents with docstring. The 
only exceptions would be interfaces to third party libraries or 
import/export, where it is sometimes needed to use std::string with a 
certain encoding. Unfortunately this conversion was never completely 
finished (this is the reason for all the "FIXME UNICODE" comments). 
Therefore, after finishing this task, all occurences of std::string would 
contain ASCII contents with very rare exceptions.
The alternative which was also discussed was to use docstring everywhere. 
This would have been less work to do, but the advantages of the mixed 
docstring/std::string approach were bugs found during the transition 
process, more memory and runtime efficiency, and (if it was completed) a 
clear picture where one can expect ASCII and where user visible contents is 
used.

The proposed changes to docstring weaken the clear separation of ASCII/non-
ASCII contents. They are not needed if the unicode transition is finished 
(i.e. all "FIXME UNICODE" comments addressed). They are not needed either if 
we change our mind and use the alternative approach of docstring everywhere 
instead. For me, the disadvantages count much higher than the advantages, 
therefore I would suggest to either finish the unicode transition, or using 
docstring everywhere. The only exception would be unicode string literals in 
C++11 mode. Support for these in docstring is both safe and useful in any 
case.

> For the record, concerning these 3 problems:
> 1/ I would agree with extending docstring so that it considers that char
> const * and std::string represent UTF8. However, I wonder what is the
> best approach for that. Making this work only for some operators seems
> strange to me. Wouldn't it be possible to set up some implicit
> constructors?

Implicit constructors do not exist on purpose, for the reason explained 
above. qt has also learned that they are problematic (see 
QT_NO_CAST_FROM_ASCII, which is actually misnamed since it disables casts 
from const char * which are implemented using fromUtf8). Recently I also 
learned that a volunteer provided a huge patch some time ago for the kate 
editor which made it use QT_NO_CAST_FROM_ASCII in order to avoid bugs.
 

Georg

Re: UTF-8 in string literals and translation strings in particular

[Guillaume Munch]

Le 08/10/2015 22:11, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


The problem with the patch is that it does not have a clear goal. The
discussion would have been much easier if you had splitted it in 3 from
the start:

1/ easy use of utf8 in docstring
2/ allow utf8 in translattable strings
3/ use … instead of ... in UI


4) use of unicode string literals in C++ source files




Thank you for the disambiguation. I included this in 2).



This would have been easier indeed. For example, I have no real opinion
about 2) and 3).

4) is not possible as long as we support C++98 (because the source encoding
is not standardized and especially MSVC has a horrible interpretation of
it).


Then, I agree this cannot go into 2.2. For 2.3, on the other hand, C++11 
opens better possibilities like directly writing docstring literals 
which is no doubt better than extending the string -> docstring conversions.





Concerning 1) I have a strong opinion which needs a bit of history
explained: When unicode support was introduced in LyX the idea was to
replace all strings which can contain non-ASCII contents with docstring. The
only exceptions would be interfaces to third party libraries or
import/export, where it is sometimes needed to use std::string with a
certain encoding. Unfortunately this conversion was never completely
finished



(this is the reason for all the "FIXME UNICODE" comments).


Good to know.


Therefore, after finishing this task, all occurences of std::string would
contain ASCII contents with very rare exceptions.
The alternative which was also discussed was to use docstring everywhere.
This would have been less work to do, but the advantages of the mixed
docstring/std::string approach were bugs found during the transition
process, more memory and runtime efficiency, and (if it was completed) a
clear picture where one can expect ASCII and where user visible contents is
used.

The proposed changes to docstring weaken the clear separation of ASCII/non-
ASCII contents. They are not needed if the unicode transition is finished
(i.e. all "FIXME UNICODE" comments addressed). They are not needed either if
we change our mind and use the alternative approach of docstring everywhere
instead. For me, the disadvantages count much higher than the advantages,
therefore I would suggest to either finish the unicode transition, or using
docstring everywhere. The only exception would be unicode string literals in
C++11 mode. Support for these in docstring is both safe and useful in any
case.



I am now convinced that string must remain ASCII.

Even independently from the issue 4) with C++98, I agree that it is 
better to wait 2.3 for C++11 support and not cast in stone a situation 
that would have been created by C++98 limitations.


So, is the plan is to change char_type from wchar_t to uchar32_t in 2.3 
and use the syntax U"..." to directly define docstring literals? Do you 
see any issues with this change? Then we do not need any conversion 
method, we can just use docstring for all purposes when non-ASCII chars 
are involved.


Now for the patch under discussion the plan become:

1/ wait for 2.3
2/ allow utf8 in translatable strings, using unicode literals.
3/ use … instead of ... in the UI (as before)

Does it make sense?

Thank you for the detailed answer.


Guillaume

Re: LyX on high resolution displays

[Georg Baum]

PhilipPirrip wrote:

> Is 2.2 going to be a Qt5 app by default (or is it up to packagers)?

2.2 will support both qt4 and qt5, where qt4 support is probably most 
important for older linux distros. The windows and Mac binaries are likely 
to be compiled with qt5.


Georg

Re: Release manager for LyX 2.2

[Liviu Andronic]

On Thu, Oct 8, 2015 at 10:17 PM, Enrico Forestieri  wrote:
> On Wed, Oct 07, 2015 at 11:08:21AM +0200, Jean-Marc Lasgouttes wrote:
>> Le 07/10/2015 11:04, Pavel Sanda a écrit :
>> >Hi all,
>> >
>> >it is very clear that we need to move forward with the release process.
>> >
>> >After the discussion with the former and current managers we agreed that 
>> >Scott
>> >Kostyshak has our trust for the role of release manager of 2.2. He has good
>> >understanding of the code and is constantly around to help with the 
>> >development
>> >process which makes him a perfect candidate.
>> >
>> >He tentatively agreed to accept such responsibility.
>> >
>> >If someone has objections to this proposal please speak now or never :)
>> >Otherwise I wish good luck to our new release manager!
>>
>> That is very good news. Scott, welcome to your new role.
>
> ACK
>
>> Besides checking everything that may go wrong, remember that the second most
>> important part of the job is to say "no"! And that's not the easiest part.
>
> Out of curiosity, what French typography dictates for a punctuation sign
> after a double quote? Shouldn't it be inside the quotes? 8-)
>
Isn't this an English peculiarity? I can't remember seeing
end-of-phrase punctuation marks within quotes in any other language...

Liviu


> --
> Enrico



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 08/10/2015 16:14, Stephan Witt wrote:

Am 08.10.2015 um 16:02 schrieb Jean-Marc Lasgouttes :


I have to admit that I did not understand Abdel's idea %-|

I understood it that way: to present the ellipsis character in the UI
there is no need to put that character with unicode in the source code.
It is possible to translate the sequence "..." to the character "…"
within the I18N process. I think the po files were not in the scope
of this discussion - they don't count as "source" files here.

Then it is exactly what my "hack" does. I attach it again for reference.

I think the idea was to let the translators do it manually where it is
appropriate. And to do it for english this way too.


Indeed :-)

Abdel

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 08/10/2015 11:58, Guillaume Munch wrote:

I think that my solution is vastly superior to these proposed
alternatives that misrepresent the problem, and that I have lifted the
technical objections and the burden for translators.


I think I mostly agree with you at this point. That being said you must 
convince the others, not me :-P


Abdel.

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 08/10/15 03:19, Cyrille Artho a écrit :

It's possible to embed characters from a font in an SVG graph; this
could be used to avoid problems with fonts that do not have all math
characters.


I seem to remember (but git log is your friend) that these icon started 
their life with embedded fonts, and that they were transformed to 
something else later.


But only Enrico can tell us what the status is.

JMarc