On 13-05-04 12:31 AM, Mikhail Zabaluev wrote: > If you are talking about gettext-like functionality, usually this and > format strings are thought of as independent processing layers: format > strings are translated as such and then fed to the formatting function. > This brings some ramifications, as the order of parameters in the > translated template can change, so the format syntax has to support > positional parameters. But this also allows to account for data-derived > context such as numeral cases, without complicating the printf-like > functions too much.
Yes, this is the sort of thing I was thinking of: that there are some pressures that a gettext() layer feed back to the selection of formatting strings that might be worth considering. Also that it might be nice to make fmt!() default-to, or very easily be adapted-to (without too much extra noise, say with ifmt!() or such) invoking the message-catalogue system. The _() macro is used in C I think due to trying to reduce the noise-effect i18n efforts have on code. We should keep that in mind. > There are other difficulties with localizing formatted messages that are > never systematically solved, for example, accounting for gender. In all, > it looks like an interesting area for library research, beyond the basic > "stick this value pretty-printed into a string" problem. There are a few of those, yes. They get quite complex. Though there is some ... "reasonably lightweight" prior art in the ICU format library that I think might be worth pursuing: http://userguide.icu-project.org/formatparse/messages https://ssl.icu-project.org/apiref/icu4j/com/ibm/icu/text/MessageFormat.html -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
