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:
<http://www.macieira.org/blog/2012/05/source-code-must-be-utf-8-and-qstring-wants-it/>.
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 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.
However I appreciate this effort of contributing positively to the
discussion.
If it was not for contributing positively, I would not be in this
community. It is normal to question all important changes and avoid
getting carried away.
The fact is that, with the patch that I posted a minute ago, I had
trouble to convince myself that the ... were replaced with …, since
the difference is quite subtle. Can you really see the difference
immediately when you use a menu?
Yes, I wish I could concentrate on the contents in LyX again and no
longer be distracted; you should tell me which fonts you use to hide the
discrepancy :) More seriously I attach screenshots with/without
ellipses. But, if the subject matter was just ellipses in the menus I
would be happy with a hack.
Y are right of course. However what is funny with this ellipsis
character is that in a monospace font it screams "look! a proper
ellipsis has not space at all" whereas on paper it is exactly the
opposite. So in the end I am not even sure which one looks good. I have
to admit that I have never been fond of these spaces out dots . . .
Le 07/10/2015, Jean-Marc Lasgouttes a écrit :
In my view, it is better to have a character that looks like the
math font that LyX uses, than a poorly designed unicode character
that smells MS Word from 100 meters. Unless we teach LyX how to use
unicode math fonts, but this is not for today.
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.
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 %-|
JMarc
