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

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

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

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

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

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

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

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

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

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. > …

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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.

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

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

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

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

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

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

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

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 +=

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

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

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

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?

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

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) +

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

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

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

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

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

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

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

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,

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

> 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

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

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:

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

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

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

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

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

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.

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

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

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

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.