Created attachment 143781 [details] [review]
Miscellaneous string fixes

Mostly capitalisation problems (e.g. with "windows" and "unix"), but there are some punctuation problems in the markup parser, and a fix for a string in GRegex which didn't follow the pattern set for all other error messages ("unrecognized character follows" rather than "unrecognized character after").

Created attachment 143782 [details] [review]
Punctuation fixes

This patch is a little more controversial, and converts Glib to using proper em-dash and ellipsis characters, rather than ASCII hyphens and dots (e.g. "—" vs. "-" and "…" vs. "..."). Other modules have been using such UTF-8 characters without problems for a few release cycles now, but committing them to Glib might be more problematic, as the compilers on embedded platforms might complain. I can't test that, so I don't know. gcc, however, is fine with them.

(In reply to comment #1)
> Created an attachment (id=143781) [details]
> Miscellaneous string fixes
> 
> Mostly capitalisation problems (e.g. with "windows" and "unix"), but there are
> some punctuation problems in the markup parser, and a fix for a string in
> GRegex which didn't follow the pattern set for all other error messages
> ("unrecognized character follows" rather than "unrecognized character after").


We are not really consistent in our spelling of UNIX, but looking over the history here, I see at least:

2001-12-13  Matthias Clasen  <matthiasc@poet.de>

        * glib/gconvert.c, glib/giochannel.c, glib/gmain.c,
        glib/gwin32.c: Revert mistaken change: it is UNIX, not Unix.

So we have preferred UNIX over Unix in the past.

(In reply to comment #2)
> Created an attachment (id=143782) [details]
> Punctuation fixes
> 
> This patch is a little more controversial, and converts Glib to using proper
> em-dash and ellipsis characters, rather than ASCII hyphens and dots (e.g. "—"
> vs. "-" and "…" vs. "..."). Other modules have been using such UTF-8 characters
> without problems for a few release cycles now, but committing them to Glib
> might be more problematic, as the compilers on embedded platforms might
> complain. I can't test that, so I don't know. gcc, however, is fine with them.

Maybe I'm oldschool, but I prefer error messages and the like (ie stuff mostly destined to the console) to stay ASCII, as far as possible.

(In reply to comment #4)
> (In reply to comment #2)
> > Created an attachment (id=143782) [details] [details]
> > Punctuation fixes
> > 
> > This patch is a little more controversial, and converts Glib to using proper
> > em-dash and ellipsis characters, rather than ASCII hyphens and dots (e.g. "—"
> > vs. "-" and "…" vs. "..."). Other modules have been using such UTF-8 characters
> > without problems for a few release cycles now, but committing them to Glib
> > might be more problematic, as the compilers on embedded platforms might
> > complain. I can't test that, so I don't know. gcc, however, is fine with them.
> 
> Maybe I'm oldschool, but I prefer error messages and the like (ie stuff mostly
> destined to the console) to stay ASCII, as far as possible.

I know it's hardly conclusive, but my console copes with such messages fine, and so does an SSH connection to master.gnome.org. Are there any terminals/terminal programs which aren't UTF-8–safe these days?

The decision on whether to use ligatures for ellipsis, fi (U-FB00),
ffi (U-FB03), etc. is font dependent.

For a fixed width font (as used by terminals if you don't want to
go crazy) the answer traditionally is "no".  TeX follows this.
This is for good reason -- just look at it!  The ffi ligature is
supposed to be a visual improvement over the separate letters,
but trying to squeeze three letters into the space of one does
no such thing!  Likewise, "..." in a fixed font really needs to
have the width of three characters.

So until and unless glib knows how you wish to present the text
in question, I believe it is better to stick with plain old ASCII.

Right, I agree with this, so lets just wontfix this. Text that gets shown in the ui is a different story, of course.