On 13-05-07 09:49 AM, Mikhail Zabaluev wrote: > What do you think of using Rust lambdas for context-sensitive > translations? That could easily accommodate any sort of variance, and > would not complicate the fmt! syntax (though it would require another > fmt-like macro to substitute, as well as mark, translated messages). > Creating message catalogs may be more challenging this way, but they > should be automatically collected and type-bracketed from the source by > a translation tool, and most of the messages would be plain strings or > have stock code patterns to fill.
I think it's relatively important that translations (in message catalog technology) be just string -> string maps. The delayed / conditional evaluation part happens dynamically, at runtime. That is: the problem isn't one of "what gets expressed in the source", it's "what gets expressed in the message catalog". If you look at the examples here: http://userguide.icu-project.org/formatparse/messages#TOC-Complex-Argument-Types and here: https://ssl.icu-project.org/apiref/icu4c/classicu_1_1SelectFormat.html the purpose is to permit a programmer to write something (say, in English) like: fmt!("{0} went to {2}") in their code, and have the _translator_ look at that and (say, if they're doing a French translation) decide it maps to a little miniature case-statement depending on the arguments: "{0} est {1, select, female {allée} other {allé}} à {2}." That is a single translation-string. It gets interpreted on the fly by the formatter, given the current locale. As such, I think it's not correct to think of this as something done "in rust code". (Note: in that example, the condition is based on argument 1, which is _not even written_ into the target string. It's just used to convey additional context-information to the format-string evaluator, by agreement between programmers and translators.) -Graydon _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
