4 ms·

I don't think it's even that bad for l10n, as you can treat the expression-like format specifiers as opaque keywords for the placeholders. For example, your i1

by efaref 11y ago

I don't think it's even that bad for l10n, as you can treat the expression-like format specifiers as opaque keywords for the placeholders. For example, your i18n tool can extract: "It's {price:.2f} and we are the {date:%m/%d/%Y}\n" as a key, and then l10n can map this to: fr_FR: "C'est {price:.2f} et nous sommes le {date:%d/%m/%Y}\n" (Here we can fix up the silly US date formatting, too, although really you shouldn't be localising dates in your format strings). All that remains is for them to work out some way of mapping in that localised string, as you can do this: _("It's {price:.2f} and we are the {date:%m/%d/%Y}\n").format(price=price, date=date) any more.

mixmastamyk 11y ago
> (Here we can fix up the silly US date formatting, too, although really you shouldn't be localising dates in your format strings). ISO 8601 (similar to Japanese format) is the most logical way to format dates: YYYY-MM-DD, easily sortable, not the silly way US and Europeans format their dates. ;) https://xkcd.com/1179/ https://xkcd.com/1179/
- scrollaway 11y ago
  Date formatting preferences are done at the desktop level and apps should query for it. All frameworks I can think of have a way of doing so, and you can just tell them "I want a long-form date & time", "I want a short date", "I want a short non-numeric date". If you are a fan of ISO8601 (which I am), you can then set this globally on your desktop, rather than expect the app developers / translators to choose for you.