Quoting John Peacock <jpeacock@rowman.com>:
> Nicolás Lichtmaier wrote:
>
> >
> >>> xgettext scans the source files wihout preprocessing them. And it
> makes
> >>> sense because any change in the text would render the translations
> >>> obsolete.
>
> Except that doesn't make sense! The whole point of preprocessing macros
> is to
> change elements of the source code based on compile-time choices. And
> that
> includes string literals. If xgettext cannot handle that, it is a
> serious
> limitation.
>
> > It could be done, but IMO format strings should be *constant* when
> using
> > gettext. So I see just two solutions, to use a function
> format_revision()
> > or just to replace this macro with the proper "%ld" and move over
> =).
>
> In this case, yes we should probably just hardcode %ld, but the use of
> macros to
> provide crossplatform format strings is widespread (some might consider
> it
> pervasive). A better way of scanning the source files (preferrably
> after
> preprocessing) would be the preferred way to deal with this, rather than
> cripple
> the code to fit xgettext's limitations.
I said before that in order to use gettext, we must get rid of all defined
format strings (ours and APRs). Scanning the files after preprocessing doesn't
help, because the format strings mmy be change between platforms, and the last
thing you want is platform-specific translations.
There are several ways to do away with defined format strings, none of them are
very nice:
-- Always use %ld (or %lu), and cast the values. Not good, because
we then truncate 64-bit values on 32-bit platforms. Unfortunately
there is no portable format string for 64-bit integers.
-- Define our own formats (e.g., %R for revision numbers) and write
our own printf format scanner that converts them to the defined
macros (urgh!)
-- Extend gettext to support macro expansion in the translations,
and use the defined macros explicitly (aargh!)
-- Convert all non-strings to strings internally, and use only %s
in the translated format strings.
I sort of feel that the last option is the closest to being feasible in the
short term.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 17:58:19 2004