Re: gettext for skeletons

[Tim Van Holder]

Joel E. Denny wrote:
> I'm very new to gettext.  It would be nice if someone who understands it 
> well would look over this patch.  I'm specifically concerned with the new 
> test case where I had to play with environment variables to make gettext 
> translate.
> 
> In any case, I think this patch is mostly good, so I committed it.
> 
> [snip]
> -                      [[%s `%s' is not used]],
> +                      address@hidden<%s `%s' is not used@>]],
> [snip]
> -b4_push_if([b4_complain([[C++ push parsers are not supported]])])
> +b4_push_if([b4_complain(address@hidden<C++ push parsers are not 
> supported@>]])])

Would a @gettext("%s `%s' is not used"@) syntax be workable?  Then you
get xgettext support for free (using 'xgettext -k @gettext:1 -L C').

Also, it looks like all messages get routed through b4_warn_at,
b4_complain, b4_fatal, which I assume end up mapped to calls to C
functions of similar name.  Would it not be simpler to add a gettext
call as part of that mapping - then all that's needed is a script
to extract the strings (and M4 seems ideally suited for that).
In fact, it looks like that's how it was implemented.  Moving the
burden of marking strings as translatable to the skeleton writers
does not make much sense to me.  The only exception I see is for
calls with arguments - having a way to tell bison that one of
the parameters needs translation (e.g. b4_fatal([[foo: %s]], [[blah]])
could be useful (although it's not recommended practice when doing i18n,
as setting up the message so that it can incorporate a separately
translated text can be hard in some languages).

Only reason I see for a patch like yours is:
- introducing translated content into the produced grammar
  -> but language should be a runtime, not compile-time choice; there's
     even a separate text domain for messages used in parsers, so it
     should be possible to emit code that does the right thing.
- giving more flexibility to the skeleton writer, like being able to use
  ngettext/dgettext/dcgettext instead of gettext if they want to.
  -> But I'm not sure using dgettext/dcgettext makes sense (the skeleton
     is part of bison after all, unless a user is supposed to be able to
     drop in their own skeletons).  And I don't know if bison requires a
     version of gettext that includes ngettext support; even if it does,
     it would make more sense to just add b4_warn_at_n (or similar) for
     those cases.

It just seems to complicate maintenance greatly to have these markers,
when all that's really needed is a good script to extract the messages.

> +## ---------------- ##
> +## @gettext<...@>.  ##
> +## ---------------- ##
> +
> +AT_SETUP(address@hidden<...@>]])
> +
> +AT_DATA([[skel.c]],
> +[[m4@&address@hidden(0)d@&address@hidden
> address@hidden(b4_parser_file_name@)d@&address@hidden
> +b4_warn(address@hidden<cannot close file@>]])d@&address@hidden
> address@hidden<cannot close file@>'
> +m4@&address@hidden(0)
> +]])
> +
> +AT_DATA([[input.y]],
> +[[%skeleton "./skel.c"
> +%%
> +start: ;
> +]])
> +
> +AT_CHECK([[LC_ALL= LC_MESSAGES= LANGUAGE=fr LANG=fr_FR bison input.y]], 
> [[0]],
> +[],
> +[[input.y: AVERTISSEMENT: ne peut fermer le fichier
> +]])
> +
> +AT_CHECK([[cat input.tab.c]], [[0]],
> +[[`ne peut fermer le fichier'
> +]])
> +
> +AT_CLEANUP

Not sure if making the testsuite rely on any particular translation is a
good idea (because those typically change late in the release cycle).
(plus I would expect the message to be "ne peut pas fermer le fichier")