[Freeipa-devel] [PATCH 69] Use indexed format specifiers in i18n strings
John Dennis
jdennis at redhat.com
Thu Apr 5 12:56:32 UTC 2012
On 04/04/2012 09:01 AM, Petr Viktorin wrote:
> On 04/02/2012 03:15 PM, Rob Crittenden wrote:
>> John Dennis wrote:
>>> Translators need to reorder messages to suit the needs of the target
>>> language. The conventional positional format specifiers (e.g. %s %d)
>>> do not permit reordering because their order is tied to the ordering
>>> of the arguments to the printf function. The fix is to use indexed
>>> format specifiers.
>>
>> I guess this looks ok but all of these errors are of the format: string
>> error, error number (and inconsistently, sometimes the reverse).
>
> Not all of them, e.g.
>
> - fprintf(stderr, _("Search for %s on rootdse failed with error %d"),
> + fprintf(stderr, _("Search for %1$s on rootdse failed with error %2$d\n"),
> root_attrs[0], ret);
>
> - fprintf(stderr, _("Failed to open keytab '%s': %s\n"), keytab,
> + fprintf(stderr, _("Failed to open keytab '%1$s': %2$s\n"), keytab,
> error_message(krberr));
>
>> Do those really need to be re-orderable?
>>
>
> You can never make too few assumptions about foreign languages. Most
> likely at least some will need reordering.
> Enforcing indexed specifiers everywhere means we don't have to worry
> about individual cases, or change our strings when a new language is added.
+1
But there is also another practical reason. The validation logic does
not have artificial intelligence and cannot parse the semantic intent of
the string. It only knows if there are multiple non-indexed specifiers.
If we want to automatically validate strings (make lint) from another
patch, we have to live with rigid application of the rules (adding
exception logic to the validator would be pretty complex because unlike
lint there is no way to tag the string that would get carried all the
way thought the xgettext process and be visible to the validator).
--
John Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeipa-devel
mailing list