Guillaume Munch wrote:
> 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
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
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
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 (b
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
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 yo
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
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
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
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 i
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 pu
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 translat
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
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
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
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 c
>
In the math panel on Mac OS X (non-Retina displays), the icons are very
pixelated. This could be due to the rendering without anti-aliasing but in
any case most of the icons look very dated due to that.
Examples are the Laplace operator ∇, the inequality signs ≤ ≦ ≮ and the
root symbols in r
Unicode characters in some menus (math panel etc.) would indeed look
much better than pixelated bitmaps.
Do you have particular examples in mind? I thought we used svg icons these
days.
In my view, it is better to have a character that looks like the math font
that LyX uses, than a poorly des
Jean-Marc Lasgouttes wrote:
Le 06/10/2015 22:17, Guillaume Munch a écrit :
I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.
Wha
On 07/10/2015 10:54, Jean-Marc Lasgouttes wrote:
Le 06/10/2015 22:17, Guillaume Munch a écrit :
I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be cons
Le 07/10/2015 01:10, Cyrille Artho a écrit :
I think for UI guidelines, if Apple and Gnome recommend A, and Microsoft
recommends B, then A is definitely the right way. ;-)
Agreed.
who knows how to get an ellipsis on his/her keyboard?
It's trivial. Character viewer -> Punctuation -> there it
Le 06/10/2015 21:43, Guillaume Munch a écrit :
-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+s.push_back(*c);
+else
+return s += from_utf8(string(c));
In the meanwhile I understood that probably the precision that y
Le 06/10/2015 20:52, Guillaume Munch a écrit :
(For proper French usage, you can also input accented upper-case
characters and I am sure that your question marks are preceded by a
space − though I would agree that a thin space would appear as too
formal in e-mails.)
Ha! You do not know who you
Le 06/10/2015 22:17, Guillaume Munch a écrit :
I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.
What would be worse than using .
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.
JMarc
Le 07/10/2015 01:23, Pavel Sanda a écrit :
Le 06/10/2015 21:01, Pavel Sanda a écrit :
I think you might be mixing issues. One thing is allowing to have
UTF-8 string literals especially in translations, another one is
deciding that we now use ? instead of ... in the interface to be
consistent with
> Le 06/10/2015 21:01, Pavel Sanda a écrit :
> I think you might be mixing issues. One thing is allowing to have
> UTF-8 string literals especially in translations, another one is
> deciding that we now use ? instead of ... in the interface to be
> consistent with Qt.
To clarify, I'm not against h
After more looking around, I see that Apple recommends the ellispsis
character:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3
Gnome seems to prefer ellipsis character too:
https://d
Le 06/10/15 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 even remeber of a document that stated that using 3 dots wa better in
French,
Le 06/10/2015 21:01, Pavel Sanda a écrit :
Guillaume Munch wrote:
Seriously, I think this is just going to annoy our translators.
Seriously :) as described in the rationale of my patch, this cannot be more
transparent for translators. Gettext pre-sets the previous translation;
translators just
Guillaume Munch wrote:
>> Seriously, I think this is just going to annoy our translators.
>
> Seriously :) as described in the rationale of my patch, this cannot be more
> transparent for translators. Gettext pre-sets the previous translation;
> translators just have to do a global search-replace
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?
P
Le 06/10/2015 20:03, Guillaume Munch a écrit :
Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :
For the docstring part of the code, I am not sure what code like the
following do:
-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+
Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :
For the docstring part of the code, I am not sure what code like the
following do:
-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+s.push_back(*c);
+else
+return s +=
Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :
Le 06/10/2015 18:38, Guillaume Munch a écrit :
I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.
Is it trivial? On my ubuntu libreoffice (where I can write
On 10/06/2015 12:38 PM, Guillaume Munch wrote:
Le 06/10/2015 17:13, Pavel Sanda a écrit :
Guillaume Munch wrote:
Le 04/10/2015 23:20, Guillaume Munch a écrit :
Dear list,
Has there been some discussion already about allowing UTF-8 in
the source code, in particular for translatable strings? Is
Le 06/10/2015 18:38, Guillaume Munch a écrit :
I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.
Is it trivial? On my ubuntu libreoffice (where I can write the same
string to compare), I would say that what i
Well, actually I am not sure that we use the same ellipsis as in English.
JMarc
Le 6 octobre 2015 18:13:25 GMT+02:00, Pavel Sanda a écrit :
>I'm trying to come up with examples where do we actually "need" unicode
>in the interface. The ellipsis case seems to be trivial indeed.
>So except that I
Le 06/10/2015 17:13, Pavel Sanda a écrit :
Guillaume Munch wrote:
Le 04/10/2015 23:20, Guillaume Munch a écrit :
Dear list,
Has there been some discussion already about allowing UTF-8 in
the source code, in particular for translatable strings? Is this
something we long for?
Guillaume
Seein
Guillaume Munch wrote:
> Le 04/10/2015 23:20, Guillaume Munch a écrit :
>> Dear list,
>>
>> Has there been some discussion already about allowing UTF-8 in the
>> source code, in particular for translatable strings? Is this
>> something we long for?
>>
>> Guillaume
>>
> Seeing how there is unanimous
Le 04/10/2015 23:20, Guillaume Munch a écrit :
Dear list,
Has there been some discussion already about allowing UTF-8 in the
source code, in particular for translatable strings? Is this
something we long for?
Guillaume
Seeing how there is unanimous interest, here's a proof of concept.
Ple
41 matches
Mail list logo
