Re: String formatting with APR_INT64_T etc. & gettext localization

Mattias Engdegård wrote:
> 25 apr 2014 kl. 18.53 skrev Julian Foad:
>
>>  1. Use PRIu64 etc. from <inttypes.h>.
>
> Good, if you can get it all to work on Windows.

No problem with a bit of configury magic. See for example <http://code.google.com/p/msinttypes/>.

>>  2. Use a helper function to format an integer as a string; insert the
> result with "%s".
>
> Probably the most practical solution for the time being.

It certainly gives the desired result for the least work in the short term. I'm trying to think a bit longer term.

>>  3. Double-formatting, using "...%%%s..." to insert the correct
> format specifier.
>
> In addition to the problems you mentioned with this approach, it yields
> unnecessarily messy strings for the translators to deal with, and possibly
> misunderstand.

Good point.

>>  4. Modify 'gettext' to expand or recognize these macros.
>>  5. Pre-process the source to expand these macros.
>
> Sounds fragile, and again, it needs to be verified on Windows.
>
>>  +    -e 's/APR_SSIZE_T_FMT/"ld"/g' \
>>  +    -e 's/APR_SIZE_T_FMT/"lu"/g' \
>>  +    -e 's/APR_OFF_T_FMT/"ld"/g' \
>
> Surely these must be wrong on IL32P64 platforms? (Why not use z?)
>
>>  +# For each file name on standard input, process the file's content into a
>>  +# new file and write the new file's name on standard output.
>
> Perhaps I have misunderstood your patch entirely, but will that really produce
> the right file names in the resulting .pot file?

The patch is a proof of concept, not a final delivery. Sorry, I should have said that.

It needs to use the correct replacement strings, of course, depending on the build platform. This can be done by configury magic. I haven't implemented that yet. And it should put the correct paths to the source file names, as you say.

At this stage, the question is whether this looks feasible and useful, or if any of these issues are insurmountable or undesirable.

- Julian
Received on 2014-04-26 15:17:46 CEST