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 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 think I do. If you look at the po/ folder, you'll find sed scripts
that converts "..." into “...” (the quotes, not the ellipsis) and that
are used to generate an EN locale. I do not know if this is still
functional, but Abdel's idea was probably to add the substitution
... → … to these scripts. But this would not be adaptable to other
languages because only EN would be automatically generated in this way.
My script is more than a sed script, it respects the previous work of
translators, and only needs to be run once after my patch is applied.
Giving the intended meaning of UI strings directly in the source is the
cleanest and more future-proof solution (now that objections about
increasing the workload of translators have been lifted).
