public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* gettext, _, N_, and G_
@ 2021-05-13 22:01 Jason Merrill
  2021-05-13 22:13 ` Jakub Jelinek
  0 siblings, 1 reply; 6+ messages in thread
From: Jason Merrill @ 2021-05-13 22:01 UTC (permalink / raw)
  To: gcc Mailing List

I understand that the difference between the _ macro and the N_ macro is
that the former is used to force a gettext call on the argument and the
latter is used for strings for which gettext will be called later.  But I
don't see any documentation about why/when we should use the G_ macro
instead of one of the other two.  It seems to be used for diagnostic
messages, for which gettext will be called in the diagnostic machinery; why
use G_ instead of N_ in such cases?

Jason

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gettext, _, N_, and G_
  2021-05-13 22:01 gettext, _, N_, and G_ Jason Merrill
@ 2021-05-13 22:13 ` Jakub Jelinek
  2021-05-14  0:56   ` Jason Merrill
  0 siblings, 1 reply; 6+ messages in thread
From: Jakub Jelinek @ 2021-05-13 22:13 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc Mailing List

On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
> I understand that the difference between the _ macro and the N_ macro is
> that the former is used to force a gettext call on the argument and the
> latter is used for strings for which gettext will be called later.  But I
> don't see any documentation about why/when we should use the G_ macro
> instead of one of the other two.  It seems to be used for diagnostic
> messages, for which gettext will be called in the diagnostic machinery; why
> use G_ instead of N_ in such cases?

See gcc/po/exgettext for details.
The two macros are:
# define N_(msgid) msgid
# define G_(gmsgid) gmsgid
and for exgettext the prefixes of the arguments determine the the kind
of format string:
    if (args ~ /g$/)
        format="gcc-internal-format"
    else if (args ~ /noc$/)
        format="no-c-format"
    else if (args ~ /c$/)
        format="c-format"
So, G_("...") results in the string being collected as
#, gcc-internal-format
while with N_("...") it is
", c-format
gettext has support for gcc-internal-format (though I wonder when that has
been updated last time) and for gcc diagnostic format specifiers will make
sure the translations handle that correctly.

	Jakub


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gettext, _, N_, and G_
  2021-05-13 22:13 ` Jakub Jelinek
@ 2021-05-14  0:56   ` Jason Merrill
  2021-05-14  7:41     ` Jakub Jelinek
  0 siblings, 1 reply; 6+ messages in thread
From: Jason Merrill @ 2021-05-14  0:56 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc Mailing List

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

On 5/13/21 6:13 PM, Jakub Jelinek wrote:
> On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
>> I understand that the difference between the _ macro and the N_ macro is
>> that the former is used to force a gettext call on the argument and the
>> latter is used for strings for which gettext will be called later.  But I
>> don't see any documentation about why/when we should use the G_ macro
>> instead of one of the other two.  It seems to be used for diagnostic
>> messages, for which gettext will be called in the diagnostic machinery; why
>> use G_ instead of N_ in such cases?
> 
> See gcc/po/exgettext for details.
> The two macros are:
> # define N_(msgid) msgid
> # define G_(gmsgid) gmsgid
> and for exgettext the prefixes of the arguments determine the the kind
> of format string:
>      if (args ~ /g$/)
>          format="gcc-internal-format"
>      else if (args ~ /noc$/)
>          format="no-c-format"
>      else if (args ~ /c$/)
>          format="c-format"
> So, G_("...") results in the string being collected as
> #, gcc-internal-format
> while with N_("...") it is
> ", c-format
> gettext has support for gcc-internal-format (though I wonder when that has
> been updated last time) and for gcc diagnostic format specifiers will make
> sure the translations handle that correctly.

Ah, I looked at exgettext but hadn't read it closely enough to 
understand that bit.  So does this look good to you?

[-- Attachment #2: 0001-intl-add-comments-to-_-N_-and-G_.patch --]
[-- Type: text/x-patch, Size: 1054 bytes --]

From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
From: Jason Merrill <jason@redhat.com>
Date: Thu, 13 May 2021 20:53:50 -0400
Subject: [PATCH] intl: add comments to _, N_, and G_
To: gcc-patches@gcc.gnu.org

gcc/ChangeLog:

	* intl.h: Add comments.
---
 gcc/intl.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gcc/intl.h b/gcc/intl.h
index 829364ae905..f21ec11ada0 100644
--- a/gcc/intl.h
+++ b/gcc/intl.h
@@ -47,14 +47,19 @@ extern const char *fake_ngettext (const char *singular, const char *plural,
 
 #endif
 
+/* Used to immediately translate the argument.  */
 #ifndef _
 # define _(msgid) gettext (msgid)
 #endif
 
+/* Used to mark strings that will be translated later.  */
 #ifndef N_
 # define N_(msgid) msgid
 #endif
 
+/* Like N_, but used for diagnostic strings, to tell gettext that this is a
+   gcc-internal-format string rather than standard c-format.  exgettext gets
+   this from the 'g' in "gmsgid", which is also used in diagnostic.c.  */
 #ifndef G_
 # define G_(gmsgid) gmsgid
 #endif
-- 
2.27.0


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gettext, _, N_, and G_
  2021-05-14  0:56   ` Jason Merrill
@ 2021-05-14  7:41     ` Jakub Jelinek
  2021-05-14  7:50       ` Jakub Jelinek
  2021-05-14 16:12       ` Jason Merrill
  0 siblings, 2 replies; 6+ messages in thread
From: Jakub Jelinek @ 2021-05-14  7:41 UTC (permalink / raw)
  To: Jason Merrill; +Cc: gcc Mailing List

On Thu, May 13, 2021 at 08:56:39PM -0400, Jason Merrill wrote:
> >From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
> From: Jason Merrill <jason@redhat.com>
> Date: Thu, 13 May 2021 20:53:50 -0400
> Subject: [PATCH] intl: add comments to _, N_, and G_
> To: gcc-patches@gcc.gnu.org
> 
> gcc/ChangeLog:
> 
> 	* intl.h: Add comments.
> ---
>  gcc/intl.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/gcc/intl.h b/gcc/intl.h
> index 829364ae905..f21ec11ada0 100644
> --- a/gcc/intl.h
> +++ b/gcc/intl.h
> @@ -47,14 +47,19 @@ extern const char *fake_ngettext (const char *singular, const char *plural,
>  
>  #endif
>  
> +/* Used to immediately translate the argument.  */
>  #ifndef _
>  # define _(msgid) gettext (msgid)
>  #endif
>  
> +/* Used to mark strings that will be translated later.  */
>  #ifndef N_
>  # define N_(msgid) msgid
>  #endif
>  
> +/* Like N_, but used for diagnostic strings, to tell gettext that this is a
> +   gcc-internal-format string rather than standard c-format.  exgettext gets
> +   this from the 'g' in "gmsgid", which is also used in diagnostic.c.  */
>  #ifndef G_
>  # define G_(gmsgid) gmsgid
>  #endif

I'd just write
/* Like N_, but for GCC diagnostic format strings.  See ABOUT-GCC-NLS for
   details.  */
for this and if something is unclear, clarify there.

	Jakub


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gettext, _, N_, and G_
  2021-05-14  7:41     ` Jakub Jelinek
@ 2021-05-14  7:50       ` Jakub Jelinek
  2021-05-14 16:12       ` Jason Merrill
  1 sibling, 0 replies; 6+ messages in thread
From: Jakub Jelinek @ 2021-05-14  7:50 UTC (permalink / raw)
  To: Jason Merrill, gcc Mailing List

On Fri, May 14, 2021 at 09:41:57AM +0200, Jakub Jelinek via Gcc wrote:
> I'd just write
> /* Like N_, but for GCC diagnostic format strings.  See ABOUT-GCC-NLS for
>    details.  */
> for this and if something is unclear, clarify there.

See https://gcc.gnu.org/legacy-ml/gcc-patches/2005-06/threads.html#00055
for further details.

	Jakub


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gettext, _, N_, and G_
  2021-05-14  7:41     ` Jakub Jelinek
  2021-05-14  7:50       ` Jakub Jelinek
@ 2021-05-14 16:12       ` Jason Merrill
  1 sibling, 0 replies; 6+ messages in thread
From: Jason Merrill @ 2021-05-14 16:12 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc Mailing List

On 5/14/21 3:41 AM, Jakub Jelinek wrote:
> On Thu, May 13, 2021 at 08:56:39PM -0400, Jason Merrill wrote:
>> >From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
>> From: Jason Merrill <jason@redhat.com>
>> Date: Thu, 13 May 2021 20:53:50 -0400
>> Subject: [PATCH] intl: add comments to _, N_, and G_
>> To: gcc-patches@gcc.gnu.org
>>
>> gcc/ChangeLog:
>>
>> 	* intl.h: Add comments.
>> ---
>>   gcc/intl.h | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/gcc/intl.h b/gcc/intl.h
>> index 829364ae905..f21ec11ada0 100644
>> --- a/gcc/intl.h
>> +++ b/gcc/intl.h
>> @@ -47,14 +47,19 @@ extern const char *fake_ngettext (const char *singular, const char *plural,
>>   
>>   #endif
>>   
>> +/* Used to immediately translate the argument.  */
>>   #ifndef _
>>   # define _(msgid) gettext (msgid)
>>   #endif
>>   
>> +/* Used to mark strings that will be translated later.  */
>>   #ifndef N_
>>   # define N_(msgid) msgid
>>   #endif
>>   
>> +/* Like N_, but used for diagnostic strings, to tell gettext that this is a
>> +   gcc-internal-format string rather than standard c-format.  exgettext gets
>> +   this from the 'g' in "gmsgid", which is also used in diagnostic.c.  */
>>   #ifndef G_
>>   # define G_(gmsgid) gmsgid
>>   #endif
> 
> I'd just write
> /* Like N_, but for GCC diagnostic format strings.  See ABOUT-GCC-NLS for
>     details.  */

Aha, that's where the documentation lives!  Committed with that change.

Jason


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-05-14 16:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-13 22:01 gettext, _, N_, and G_ Jason Merrill
2021-05-13 22:13 ` Jakub Jelinek
2021-05-14  0:56   ` Jason Merrill
2021-05-14  7:41     ` Jakub Jelinek
2021-05-14  7:50       ` Jakub Jelinek
2021-05-14 16:12       ` Jason Merrill

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).