bugmake - Bugs: bug #34530, make (ab)uses the ASCII grave...

 
 

bug #34530: make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Submitter:  Dan Kegel <dankegel>
Submitted:  Tue 11 Oct 2011 04:58:03 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.82 Operating System:  None
Fixed Release:  4.0 Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 04 Mar 2012 12:25:57 AM UTC, comment #8: 

I committed this change, as per the new GNU Coding Standards guidelines.  Note I checked the translations and apparently the gettext engine is smart enough to manage this change, as all the translations (that worked before) still appear to be working properly after the change.

Paul D. Smith <psmith>
Group administrator
Mon 16 Jan 2012 11:21:01 PM UTC, comment #7: 

After some discussion recently by the GNU maintainers, the coding standards have been modified:

http://www.gnu.org/prep/standards/html_node/Quote-Characters.html


In the C locale, the output of GNU programs should stick to plain ASCII for quotation characters in messages to users: preferably 0x22 (‘"’) or 0x27 (‘'’) for both opening and closing quotes. Although GNU programs traditionally used 0x60 (‘`’) for opening and 0x27 (‘'’) for closing quotes, nowadays quotes ‘`like this'’ are typically rendered asymmetrically, so quoting ‘"like this"’ or ‘'like this'’ typically looks better.


Paul D. Smith <psmith>
Group administrator
Sun 13 Nov 2011 10:53:55 PM UTC, comment #6: 

The strings are the keys to the translation lookup table, yes.  So changing the string changes the lookup key.  I don't know what you mean by "change the hashes at our end"?  The hashes are generated at runtime by the gettext library when you ask for the translation of a string.

As for updating the translation files with the new key values, we do not store the translations ourselves (if you check CVS you'll see there are no translation files there).  They are stored by the GNU Translation project and when we build GNU make for distribution we download the latest versions from there.  If you wanted to update the translations yourself you'd need to modify the translation files and send them up to the translation teams so those changes could be incorporated by them.

In any event, as I've said, I'm not going to make this change without a consensus of the GNU project, regardless of how much effort that will be.  For good or bad this is the standard behavior for the GNU project and GNU make is part of the GNU project.  This is just as if someone wanted to change the coding standard for GNU make: you have to change the GNU coding standard, which GNU make uses.  That's the only way this will happen.

Paul D. Smith <psmith>
Group administrator
Sun 13 Nov 2011 09:43:01 PM UTC, comment #5: 

I was assuming that the strings itself are they keys, already.
Would technically be possible for us to fix the hashes on our end to save the translators the trouble but still fix the trouble?

I'm unsure if bouncing this back up to GNU level is a step forward.  It would need either someone to dictate the change, everyone to agree or majority votes for a topic that has chances to either cause flamewars or face broad ignorance.  It could take ages and easily drift off to nowhere or worse.  And suck energy and time better spent elsewhere.

So my proposal is to make the switch at make level and let Markus do the patching for you if he can.  In case he cannot, maybe I can, but that would be January 2012 or later.

Sebastian Pipping <hartwork>
Sun 13 Nov 2011 09:00:20 PM UTC, comment #4: 

Eli: Using '' or "" instead of `' is also pure ASCII...?  I agree with Markus, really, that this is a throwback to broken terminal fonts from the 1980's, that it looks ugly in virtually every font available today, and I don't see any reason to perpetuate the brokenness into the next century.


Sebastian: definitely it will hit translators.  The way gettext works is that the string itself is used as a hash key to look up the translation.  This is the neat thing about gettext and how it avoids the painful "message catalog numbers" of other solutions.

However it means that any single character change in the string, even whitespace or some other innocuous character, changes the hash and requires translators to update their translations.


Anyway, if Dan or Markus want this changed then they should bring it up on one of the general GNU discussion lists and get a general consensus that it's the direction we want to move in, and if that's done I'm happy to do my part as well.

Paul D. Smith <psmith>
Group administrator
Sun 13 Nov 2011 08:38:17 PM UTC, comment #3: 

If Markus is on a crusade for it, does that make him wrong?
I thought we were on a joint crusade for free software with GNU make.

Paul, are you sure such a change would even be hitting translators?  Either `foo' has been translated to `foo' so we knew what to fix it to ourselves.  Or it has been translated to a better suitable tick in which case we would only have to touch the translation source side on that case.  Am I missing anything?

Sebastian Pipping <hartwork>
Sun 13 Nov 2011 08:27:56 PM UTC, comment #2: 

I wouldn't worry about this.  Markus is on a crusade to eliminate the use of `...' for many years.  By contrast, in GNU projects it's a long-standing tradition and at least a de-facto standard to use this kind of quoting, because it's pure ASCII.

Suggest to close this as "wontfix".

Eli Zaretskii <eliz>
Group Member
Sun 13 Nov 2011 07:55:56 PM UTC, comment #1: 

I'm not too excited about GNU make becoming the poster child for the remediation of this behavior.  As Markus points out, this issue is endemic throughout all GNU programs.  Also the last time this came up (quite a while ago) there was a discussion with a number of the maintainers of other GNU projects (but now I can't find it after searching through some likely-looking lists) and it seemed people didn't think this was something we should do.

Of course maybe that's changed since: Markus is right IMO that every year this gets more annoying.

If there's some kind of general decision that going forward GNU projects should move back to '' rather than `' I'll be happy to fix GNU make (although translators will hate me...)

Paul D. Smith <psmith>
Group administrator
Tue 11 Oct 2011 04:58:03 PM UTC, original submission:  

As Markus wrote in
http://lists.gnu.org/archive/html/bug-make/2004-10/msg00013.html
gnu make uses funny quotes in error messages. 
This behavior persists in Make 3.82.

Here's his original message:

$ make --version GNU Make 3.80
$ make love
make: * No rule to make target `love'.  Stop.
                                 ^

The use of ASCII character 0x60 as a left single quotation mark is deprecated and looks today rather ugly with most contemporary fonts.

Suggested behavior (in the C and POSIX locales, i.e. without translation):

$ make love
make: * No rule to make target 'love'.  Stop.
                                 ^
In other locales, such as en_*.UTF-8, the straight single quotation mark
(U+0027) can easily be translated via gettext() with the typographically
nicer ones (U+2018 and U+2019) available in UTF-8 and some other
encodings.

Suggested fix:

 a) s/`/'/g
 b) use Unicode quotation marks in the translations for
    en_GB.UTF-8 and en_US.UTF-8

Detailed background information:

  http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

Dan Kegel <dankegel>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hartwork (Posted a comment)
  • -email is unavailable- added by eliz (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dankegel (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-04 psmith StatusLater Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2011-11-13 psmith StatusNone Later
        Triage StatusNone Medium Effort

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code