From m|ch@e|ch|r|co4 @end|ng |rom gm@||@com  Thu Jun  4 06:04:12 2020
From: m|ch@e|ch|r|co4 @end|ng |rom gm@||@com (Michael Chirico)
Date: Thu, 4 Jun 2020 12:04:12 +0800
Subject: [Rd] Translations and snprintf on Windows
In-Reply-To: <CAPRVBcx9rZQx7rFQj-a6KK+6LXPi5t_2p0NXte9HAjY9F5tP4g@mail.gmail.com>
References: <CAPRVBcx9rZQx7rFQj-a6KK+6LXPi5t_2p0NXte9HAjY9F5tP4g@mail.gmail.com>
Message-ID: <CAPRVBczmyZJ4y=SF_k6qw2pQ3e=9zP2B1UiE2Py2qy371VvKgw-1294@mail.gmail.com>

Following up on this after Matt D truffled out the issue -- snprintf was a
*bit* of a red herring.

The root of the issue is the use of positional identifiers (like %1$d, see
https://stackoverflow.com/questions/19327441/gcc-dollar-sign-in-printf-format-string)
in the format string for translations.

These identifiers are quite useful for translations since grammar changes
by language mean the inputs should naturally change order when changing
languages -- however, they are a POSIX extension.

snprintf produced the issue since all other messages are ultimately R
functions, and base R handles the issue (AFAICT via trioremap.h).


On Thu, Apr 30, 2020 at 4:16 PM Michael Chirico <michaelchirico4 at gmail.com>
wrote:

> [a bit unsure on if this is maybe better for r-package-devel]
>
> We recently added translations to messages at the R and C level to
> data.table.
>
> At the C level, we did _() wrapping for char arrays supplied to the
> following functions: error, warning, Rprintf, Error, and snprintf.
>
> This seemed OK but the use of snprintf specifically appears to have caused
> a crash on Windows:
>
> https://github.com/Rdatatable/data.table/issues/4402
>
> Is there any guidance against using gettext with snprintf, or perhaps
> guidance on which "outputters" *are* OK for translation?
>
> Michael Chirico
>

	[[alternative HTML version deleted]]



[Rd] Translations and snprintf on Windows
Michael Chirico