On 13-05-09 10:49 PM, Mikhail Zabaluev wrote:
> I agree. And if expressions are in Rust, you get the benefit of a Rust
> compiler validating them. A lambda must produce _some_ string to be
> valid; match clauses will be checked for correct type and coverage.
> Dynamically interpreted syntax engines do not usually give this benefit
> and may in fact let the translator unwittingly and quietly introduce
> runtime errors, which are less likely to be caught the farther off the
> beaten track the language is (I may be bitter at my EU-market Samsung
> TV, that has the Russian language option for the UI, but starts crashing
> randomly if you switch to it; no grudge against the Samsung folks on
> this list).
The sublanguage is non-effectful, non-stateful, non-turing-complete, and
has no functions. Evaluation time is linear and harmless if it fails: it
can just use the default (non-translated -- wrong language) format if
interpretation goes wrong.
I will reiterate why I keep objecting to "using rust code" as both the
wrong answer and an answer to the wrong question:
- Dynamic loading of translations currently happens in the deployment
environment. If you require rust code, you're requiring a dynamic
load of a .so or .dll rather than reading a .po file for a string.
- There are extensive existing toolchains, processes and communities
who have no interest in learning to program in rust to (eg.)
translate a web browser or consumer product.
http://www.poedit.net/screenshots.php
https://en.wikipedia.org/wiki/Virtaal
http://mozilla.locamotion.org/
http://weblate.org/en/
http://sourceforge.net/projects/translate/
etc. etc.
- The whole point of this thread is to _design_ a formatting
mini-language. If "plain rust code" was sufficient for this,
people would write:
let x = do fmt::with_sfmt_writer |f| {
f.putstr("there are ");
a.fmtD(f);
f.putstr(" files in the folder");
};
rather than:
let x = fmt!("there are %d files in the folder", a);
Yet here we are discussing that format-string mini-language.
So all I'm saying is: given that we _are_ discussing the design
of a held-in-a-format-string mini-language, why not make sure
that design scales nicely to cases when a translator has to
express the little bits of logic they often do, such as:
"there {num_files, plural,
one {is one file}
other {are {num_files} files}} in the folder"
This is relatively easy to adopt as an extension to {}-based
format strings, whereas it's tricker with %s-based.
I think this thread keeps going repeatedly off into discussion of
problems we are not facing. We're not trying to eliminate format-string
mini-languages from rust: we're trying to design one. We're not trying
to solve all hypothetical turing-complete translation tasks: we're
trying to accommodate the level of translation-variability that normal
translators (even people writing non-translated format strings in their
home language) run into all the time when composing format strings.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
