As for that library, I heavily suggest letting translators manipulate Rust code 
directly. I see it as no more difficult than asking them to learn a special 
micro-language that keeps evolving and pattern-matching is really adapted for 
the task at hand.
I'd like to react to this.
If the translators have to write Rust code instead of interpretable strings, it 
most likely means that they now have to set up a full development environment. 
This alone can be blocking.
Ok, let's say that they don't have to do so, because the i18n system is smart 
enough to dynamically compile and load the rust code written by the 
translators. There is still another, bigger problem : the code can be wrong. It 
can be invalid Rust code, or it can contain a bug that will blow the whole 
application at runtime, or more likely it will be out of sync with the 
application.
With a good i18n system, an ill-formatted or "buggy" translation cannot break 
the program. The resulting string would be either the raw translation (without 
interpretation), or it will fall back to the english (original) string. Knowing 
that a translation cannot break the program is a really nice guarantee ! And 
knowing that it cannot introduce security risks is great, too !
I said that the translation will likely be out of sync, because this is how 
translations work. The programmer and the translators must be able to work at 
their own pace. Let's say a program is translated in 10 languages, and a 
programmer updates a translated string in the code by adding a new parameter. 
Now, with a "translations using rust code" system, he has to update the 10 
translations correctly, just for the application to compile happily. This is 
plain impossible. He can also add the parameter and intentionally break the 
build, and wait for all 10 translators to fix this update in their 
transaltions. There is clearly a problem, with this solution...
The manual of Gettext explains quite well the "continuous" nature of the i18n 
process : http://www.gnu.org/software/gettext/manual/gettext.html#Overview
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to