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

Submitted by:  Dan Kegel <dankegel>
Submitted on:  Tue 11 Oct 2011 04:58:03 PM UTC  
 
Severity: 3 - NormalItem Group: Enhancement
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.82Operating System: None
Fixed Release: 4.0Triage Status: Medium Effort

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 04 Mar 2012 12:25:57 AM UTCpsmithStatusLater=>Fixed
      Assigned toNone=>psmith
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0
    Sun 13 Nov 2011 07:55:56 PM UTCpsmithStatusNone=>Later
      Triage StatusNone=>Medium Effort

    Back to the top


    Powered by Savane 3.1-cleanup