[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is it woth to have SVN_REVNUM_T_FMT?

From: C.A.T.Magic <c.a.t.magic_at_gmx.at>
Date: 2004-04-05 18:45:18 CEST

Branko Cibej wrote:

> 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!)

why doesn't
      apr_file_printf
do this by itself?
this way you could get rid of all these weird
      apr_file_printf(out, "%" APR_SIZE_T_FMT " bytes were read\n",
                     total_bytes);
constructs at the same time.
I think APR could even be modified for this without creating
incompatibilities with existing applications,
because "%" APR_SIZE_T_FMT " bytes" would simply resolve to
something like "%Z bytes" for all applications.
but i don't know the design decisions for this in APR.

> -- 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.

a little more work for implementing a special printf will make
your life much easier than to wade through the code and change
everything a second time after that "short term" :-)
and a later change of the syntax may render 20 language files unusable...

:-)
c.a.t.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 18:45:30 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.