Re: Using the Unicode ellipsis (…) instead of three periods
on., 05.12.2012 kl. 09.56 -0500, skrev Shaun McCance: On Tue, 2012-12-04 at 17:24 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 1:48 PM, Philip Withnall phi...@tecnocode.co.uk wrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... It hadn't occurred to me to make the time display on audio/video controls translatable in yelp-xsl. I used to mark a lot more for translation, but I scaled back on the formatting stuff when I saw nobody did legitimate translations of them. I looked at the po files in totem and gnome-shell. Nobody seems to actually translate how times are formatted. Date format, yes. And there's the difference between using 12- or 24-hour clocks. But when it comes down to the format HH:MM:SS, nobody translates it. It's always the same. I always try to translate time to HH.MM.SS for Norwegian. Maybe I missed that in yelp-xsl, but then it's just a bug in the translation. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash (was: Re: Using the Unicode ellipsis (…) instead of three periods)
On Mon, 2012-12-10 at 13:15 -0500, Shaun McCance wrote: But if we're going to write guidelines, here's my semi-professinal opinion: * Using hyphens instead of dashes for parenthetical text is awful. Using unspaced hyphens-like this-is downright confusing. * I'm old and I like unspaced em-dashes (a). A lot of people these days are switching to spaced en-dashes (b). I think that trend will continue. * Spaced em-dashes (c) are way too wide. * Unspaced en-dashes are for indicating ranges. We should use those too, though the hyphen isn't quite as ugly when misused in this case. Compelling. I’ve updated the wiki page to standardise on spaced en-dashes. https://live.gnome.org/GnomeGoals/UnicodeUsage The only characters left which need discussion are quotation marks. After looking through a few UI guidelines, the consensus seems to be to either: • use double quotation marks everywhere; or • use italics when referring to UI elements and double quotation marks otherwise (Microsoft’s guidelines). LibreOffice’s guidelines are the only ones which required using _single_ quotes, but that’s for technical reasons (they didn’t used to be able to escape double quotes). This seems fairly conclusive. From a quick look through Totem’s POT file, quotation marks are mainly used for quoting file names at the moment. UI labels are often quoted when referenced as well. Personally I quite like the idea of reducing punctuation clutter by using text styling (italics, monospace, or something else) for identifying UI labels and filenames. Mallard renders gui elements in a different colour to the rest of the text, for example, rather than quoting them. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash (was: Re: Using the Unicode ellipsis (…) instead of three periods)
On Mon, 2012-12-10 at 13:15 -0500, Shaun McCance wrote: * Unspaced en-dashes are for indicating ranges. We should use those too, though the hyphen isn't quite as ugly when misused in this case. Since this one should be fairly uncontroversial, I’ve added it to the wiki page with the note that ‘to’ should be used if the dash could be confused with subtraction. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
En-dash versus em-dash (was: Re: Using the Unicode ellipsis (…) instead of three periods)
Philip Withnall wrote: I’ve created https://live.gnome.org/GnomeGoals/UnicodeUsage which I think covers everything discussed in this thread so far. Please feel free to add further suggestions to it, or move things from the ‘discussion’ to the ‘agreed’ list. Looks good. The only thing I’d like to discuss is the use of a spaced em-dash: Em-dash (U+2014, ‘—’) rather than a hyphen (‘-’) in longer descriptive strings. The em-dash should be used similarly to a colon — to mark an abrupt change or conclusion to a sentence. For example: “hyphens should not be used — they are too narrow” rather than “hyphens should not be used - they are too narrow”. I agree that hyphens should not be used for the above purposes. The common alternatives are the following: a) Em-dash without spaces: Hyphens should not be used—they are too narrow b) En-dash with spaces: Hyphens should not be used – they are too narrow c) Em-dash with spaces: Hyphens should not be used — they are too narrow (Please remember to look at these examples in a proportional font, not a fixed-width one.) Also see the following section about this: http://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash IMO either style a) or b) from above should be chosen, as they are more widely used than c) in general. I personally prefer b), because a) “glues” the words together and c) spaces them too far apart. Any other opinions on this? Regards, Robin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash (was: Re: Using the Unicode ellipsis (…) instead of three periods)
On Mon, 2012-12-10 at 12:50 +0100, Robin Stocker wrote: Philip Withnall wrote: I’ve created https://live.gnome.org/GnomeGoals/UnicodeUsage which I think covers everything discussed in this thread so far. Please feel free to add further suggestions to it, or move things from the ‘discussion’ to the ‘agreed’ list. Looks good. The only thing I’d like to discuss is the use of a spaced em-dash: Em-dash (U+2014, ‘—’) rather than a hyphen (‘-’) in longer descriptive strings. The em-dash should be used similarly to a colon — to mark an abrupt change or conclusion to a sentence. For example: “hyphens should not be used — they are too narrow” rather than “hyphens should not be used - they are too narrow”. I agree that hyphens should not be used for the above purposes. The common alternatives are the following: a) Em-dash without spaces: Hyphens should not be used—they are too narrow b) En-dash with spaces: Hyphens should not be used – they are too narrow c) Em-dash with spaces: Hyphens should not be used — they are too narrow (Please remember to look at these examples in a proportional font, not a fixed-width one.) Also see the following section about this: http://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash IMO either style a) or b) from above should be chosen, as they are more widely used than c) in general. I personally prefer b), because a) “glues” the words together and c) spaces them too far apart. Any other opinions on this? Good point. I guess we first need to make the distinction between dashes being used parenthetically – like this – and dashes which are used to conclude a sentence — like this. As the third paragraph you cite on Wikipedia points out, word spacing can be messed up if dashes are not surrounded by spaces, so that limits us to styles b) and c) in both cases. In order to differentiate between parenthetical and conclusive use, I suggest we go with b) for parenthetical usage and c) for demarcating conclusions or abrupt changes in the sentence. However, this doesn’t fit with any particular manual of style. IMO, spaced em-dashes work well, but nobody else seems to think that. Disclaimer: I’m en_GB. I’m not entirely sure that en_GB speakers should be deciding the style to use in the C locale, given that manuals of style differ between the UK and the US. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash (was: Re: Using the Unicode ellipsis (…) instead of three periods)
On Mon, 2012-12-10 at 12:50 +0100, Robin Stocker wrote: Philip Withnall wrote: I’ve created https://live.gnome.org/GnomeGoals/UnicodeUsage which I think covers everything discussed in this thread so far. Please feel free to add further suggestions to it, or move things from the ‘discussion’ to the ‘agreed’ list. Looks good. The only thing I’d like to discuss is the use of a spaced em-dash: Em-dash (U+2014, ‘—’) rather than a hyphen (‘-’) in longer descriptive strings. The em-dash should be used similarly to a colon — to mark an abrupt change or conclusion to a sentence. For example: “hyphens should not be used — they are too narrow” rather than “hyphens should not be used - they are too narrow”. I agree that hyphens should not be used for the above purposes. The common alternatives are the following: a) Em-dash without spaces: Hyphens should not be used—they are too narrow b) En-dash with spaces: Hyphens should not be used – they are too narrow c) Em-dash with spaces: Hyphens should not be used — they are too narrow (Please remember to look at these examples in a proportional font, not a fixed-width one.) Also see the following section about this: http://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash IMO either style a) or b) from above should be chosen, as they are more widely used than c) in general. I personally prefer b), because a) “glues” the words together and c) spaces them too far apart. Any other opinions on this? d) If you have parenthetical text, your sentence is too complicated for user interface text. Rewrite it. But if we're going to write guidelines, here's my semi-professinal opinion: * Using hyphens instead of dashes for parenthetical text is awful. Using unspaced hyphens-like this-is downright confusing. * I'm old and I like unspaced em-dashes (a). A lot of people these days are switching to spaced en-dashes (b). I think that trend will continue. * Spaced em-dashes (c) are way too wide. * Unspaced en-dashes are for indicating ranges. We should use those too, though the hyphen isn't quite as ugly when misused in this case. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Sat, 2012-12-08 at 10:01 +0100, Stefan Sauer wrote: On 12/04/2012 01:09 AM, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. It would be awesome to have a wiki page with the agreed and proposed uni-code character usage. Once there are enough agreed use-cases (e.g. the use of ellipsis in menus), it could be turned into a gnome goal. Ideally the agreed uni-code characters would make it into a gnome hig chapter about typography. I’ve created https://live.gnome.org/GnomeGoals/UnicodeUsage which I think covers everything discussed in this thread so far. Please feel free to add further suggestions to it, or move things from the ‘discussion’ to the ‘agreed’ list. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On 12/04/2012 01:09 AM, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. It would be awesome to have a wiki page with the agreed and proposed uni-code character usage. Once there are enough agreed use-cases (e.g. the use of ellipsis in menus), it could be turned into a gnome goal. Ideally the agreed uni-code characters would make it into a gnome hig chapter about typography. Stefan Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, 2012-12-04 at 17:30 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 5:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... and, to finish that thought, therefore the behavior of the en_US time format in rtl locales is not really relevant. Sounds reasonable to me. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Wed, Dec 5, 2012 at 5:30 AM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, Dec 4, 2012 at 5:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... and, to finish that thought, therefore the behavior of the en_US time format in rtl locales is not really relevant. So this change will be in en_US.po, not in .pot file? The reason is many translators will simply copy the original string down. Even if one knows about this, it's really hard to know which one is colon, which is ratio by just looking at it. -- Duy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Wed, Dec 5, 2012 at 6:40 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: So this change will be in en_US.po, not in .pot file? The reason is many translators will simply copy the original string down. Even if one knows about this, it's really hard to know which one is colon, which is ratio by just looking at it. There's a translator comment which explains the special characters in the string. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Wed, Dec 5, 2012 at 7:37 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Dec 5, 2012 at 6:40 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: So this change will be in en_US.po, not in .pot file? The reason is many translators will simply copy the original string down. Even if one knows about this, it's really hard to know which one is colon, which is ratio by just looking at it. There's a translator comment which explains the special characters in the string. Yeah. I remember seeing Bastien or someone complain about comments about key names in gtk+ being ignored by translators. I would not count too much on it. -- Duy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Wed, 2012-12-05 at 20:32 +0700, Nguyen Thai Ngoc Duy wrote: On Wed, Dec 5, 2012 at 7:37 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Dec 5, 2012 at 6:40 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: So this change will be in en_US.po, not in .pot file? The reason is many translators will simply copy the original string down. Even if one knows about this, it's really hard to know which one is colon, which is ratio by just looking at it. There's a translator comment which explains the special characters in the string. Yeah. I remember seeing Bastien or someone complain about comments about key names in gtk+ being ignored by translators. I would not count too much on it. I probably did when all the clutter applications were crashing when launched in Brazilian Portuguese: http://git.gnome.org/browse/clutter/commit/?id=8d234d270a00abee8c46561903193097de78efe3 Given the patch, it's also possible that translator comments don't get fed back into existing translations. So might be a tools problem as well as one with the translators. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Wed, Dec 5, 2012 at 8:38 PM, Bastien Nocera had...@hadess.net wrote: Yeah. I remember seeing Bastien or someone complain about comments about key names in gtk+ being ignored by translators. I would not count too much on it. I probably did when all the clutter applications were crashing when launched in Brazilian Portuguese: http://git.gnome.org/browse/clutter/commit/?id=8d234d270a00abee8c46561903193097de78efe3 That one too, but I was thinking about this http://thread.gmane.org/gmane.comp.gnome.release-team/400 I'm a translator and am aware of these translator comments. Still I find myself ignoring them sometimes (especially after translating hundreds of strings). Please don't put big decisions on translator comments. Given the patch, it's also possible that translator comments don't get fed back into existing translations. So might be a tools problem as well as one with the translators. Tools definitely improve the situation where there is limited number of options like this. For colon/ratio thing it's harder because the tool writer must know about all supported language. Most importantly no such tool exists yet, or not announced on gnome-i18n. If someone is willing to write it _then_ replace colon with ratio character, it'd be nice. The other way just makes the matter worse. -- Duy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, 2012-12-04 at 17:24 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 1:48 PM, Philip Withnall phi...@tecnocode.co.uk wrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... It hadn't occurred to me to make the time display on audio/video controls translatable in yelp-xsl. I used to mark a lot more for translation, but I scaled back on the formatting stuff when I saw nobody did legitimate translations of them. I looked at the po files in totem and gnome-shell. Nobody seems to actually translate how times are formatted. Date format, yes. And there's the difference between using 12- or 24-hour clocks. But when it comes down to the format HH:MM:SS, nobody translates it. It's always the same. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Mon, 2012-12-03 at 22:01 -0600, Ted Gould wrote: On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). We've been trying to do this on the Unity Indicators and I wrote a small automake fragment to test for them. It's a little bit hacky, but it works and makes sure we don't regress. I'd love for it to get used and improved in other projects. http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings That looks really useful! Perhaps it could get included in gnome-common and then used in GNOME projects? Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 GTK+ has just switched to using Unicode ellipses[1], and there’s a tracker bug[2] open for the rest of the desktop. It would be great to get some momentum behind this. Philip [1]: http://git.gnome.org/browse/gtk +/commit/?id=ceb866dfe6be6d88b8f83a3cbdb8a2a688419c82 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=621639 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On 2012-12-04 09:08, Philip Withnall phi...@tecnocode.co.uk wrote: On Mon, 2012-12-03 at 22:01 -0600, Ted Gould wrote: On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). We've been trying to do this on the Unity Indicators and I wrote a small automake fragment to test for them. It's a little bit hacky, but it works and makes sure we don't regress. I'd love for it to get used and improved in other projects. http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings That looks really useful! Perhaps it could get included in gnome-common and then used in GNOME projects? Looks good to me! Ted or Philip, can you file a bug against gnome-common? If there is to be a GNOME Goal for this (and the other checks, such as ‘spaces before ellipsis’) it would be good to get gnome-common to offer some assistance. -- http://amigadave.com/ pgpfEuUkvKtR2.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 7:09 AM, Jeremy Bicha jbi...@ubuntu.com wrote: On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. Please stick with ASCII for command line programs. When I get problems and have to use real console (no X11), the last thing I want is font problem. -- Duy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, 2012-12-04 at 09:40 +, David King wrote: On 2012-12-04 09:08, Philip Withnall phi...@tecnocode.co.uk wrote: On Mon, 2012-12-03 at 22:01 -0600, Ted Gould wrote: On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). We've been trying to do this on the Unity Indicators and I wrote a small automake fragment to test for them. It's a little bit hacky, but it works and makes sure we don't regress. I'd love for it to get used and improved in other projects. http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings That looks really useful! Perhaps it could get included in gnome-common and then used in GNOME projects? Looks good to me! Ted or Philip, can you file a bug against gnome-common? If there is to be a GNOME Goal for this (and the other checks, such as ‘spaces before ellipsis’) it would be good to get gnome-common to offer some assistance. Filed! I’ve added Ted to the CC list. https://bugzilla.gnome.org/show_bug.cgi?id=689602 Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
While we are talking about better use of Unicode, I've recently spent some time improving the time rendering in a few prominent places, by using the 'ratio' character instead of plain ascii : - some screenshots of the difference can be seen in bug 689184 [1]. It might be a good idea to do this consistently throughout the desktop. I only got as far as gnome-shell and gnome-clocks... Matthias [1] https://bugzilla.gnome.org/show_bug.cgi?id=689184 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
Le lundi 03 décembre 2012 à 19:09 -0500, Jeremy Bicha a écrit : I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. The Microsoft link recommends using curly quotes instead of straight ones too. Do you think this is a valuable change too? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, 2012-12-04 at 06:40 -0500, Matthias Clasen wrote: While we are talking about better use of Unicode, I've recently spent some time improving the time rendering in a few prominent places, by using the 'ratio' character instead of plain ascii : - some screenshots of the difference can be seen in bug 689184 [1]. It might be a good idea to do this consistently throughout the desktop. I only got as far as gnome-shell and gnome-clocks... Matthias [1] https://bugzilla.gnome.org/show_bug.cgi?id=689184 Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On 4 December 2012 09:21, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? Colon: http://bugzilla-attachments.gnome.org/attachment.cgi?id=230039 Ratio: http://bugzilla-attachments.gnome.org/attachment.cgi?id=230150 The biggest difference I see is that the colon sits on the baseline while the ratio is nicely centered. I like how Android 4.2 appears to use both styles: http://i.imgur.com/y2zVX.png Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 12:48 PM, Philip Withnall phi...@tecnocode.co.ukwrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? Is that a rhetorical question? I think you should comment on the bug. Meg Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 1:48 PM, Philip Withnall phi...@tecnocode.co.uk wrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Tue, Dec 4, 2012 at 5:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... and, to finish that thought, therefore the behavior of the en_US time format in rtl locales is not really relevant. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Using the Unicode ellipsis (…) instead of three periods
I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote: I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). We've been trying to do this on the Unity Indicators and I wrote a small automake fragment to test for them. It's a little bit hacky, but it works and makes sure we don't regress. I'd love for it to get used and improved in other projects. http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
