This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran,patch] Internationalisation of the Fortran front-end
- From: François-Xavier Coudert <fxcoudert at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: patch <gcc-patches at gcc dot gnu dot org>, fortran at gcc dot gnu dot org
- Date: Thu, 1 Sep 2005 14:25:29 +0200
- Subject: Re: [gfortran,patch] Internationalisation of the Fortran front-end
- References: <4314B863.3000804@gmail.com> <Pine.LNX.4.61.0508302232130.4521@digraph.polyomino.org.uk> <19c433eb05090102423f59716a@mail.gmail.com> <Pine.LNX.4.61.0509011055320.18627@digraph.polyomino.org.uk>
> Not marking them as special formats (using msgid not gmsgid) is the
> simplest way for now.
I did that, but some of the strings in the generated gcc.pot are
marked as c-format. In fact, the strings that contains valid
printf-style format are marked as c-formats, while those containing
invalid printf-style format are not marked. Example:
gfc_error ("Expected array subscript at %C") is marked as c-format,
because %C is a valid printf-style format; in fact, it is used here in
gfortran internal format to represent the current locus.
gfc_error ("Iterator step at %L cannot be zero") is not marked,
because %L is not a valid printf-style format; it is used to represent
a locus provided as argument in gfortran.
What is the solution to that? How can I get gettext not to be too clever?
FX