Hi,
On 29/07/2013 06:24, Alex Crichton wrote:
Having thought a bit more concretely about this, using the suggestions here,
and talking to Graydon on IRC I've come up with the following design for a
string formatting library. I think that this addresses the comments in the
responses to my original email, but if not please let me know!
I love the proposal. I have been hoping for extensible and rearrangable
formatting for a really long time. Just a few notes on i18n support.
A few notes:
* I believe that parsing must occur at runtime, because otherwise i18n
wouldn't work because it could generate any arbitrary format string at
runtime based on the current locale.
Can we have both? Parse at compile time if the string is constant but
parse at compile time if the string comes from something like a
gettext-ish function that loads the string from a message catalog.
I also wanted to touch on how this covers internationalization. The main point
of this is located within the query language, but the runtime must also support
some constructs. The format string and arguments are validated at compile-time,
but any format string could be run at runtime. For this reason an equivalence
function will be needed that takes the original format string and a translated
format string and ensures at runtime that the two are equivalent in terms of
types, position, and number of arguments.
Having done some i18n work through Babel i can tell you that people
vastly prefer keyword based syntax over positional one. Granted, part
of it is because in Babel (which uses old Python printf style
formatting) you can rearrange them. A bit part of the reason however is
because sometimes translations lag behind and a new argument was added
later. If that new argument does not show up in the new format string
it's silently ignored.
The whole translation workflow should not be forgotten. Very few
projects can afford to not have translations lagging behind. I believe
formatting for i18n should be as lenient as possible, something that
does not hold true for normal format strings. Maybe some compromise can
be added to have strictness levels on the formatting?
Regards,
Armin
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
