Markus Glaser
<glaser(a)hallowelt.biz> wrote:
Hello,
The right way to do it is to have a test suite: A
document that walks
the translator through all the use cases of the feature so that all
possible messages permutations and combinations appear.
Possibly, Selenium tests could be helpful. A Selenium test basically
acts as a remote control for a browser. So a test could walk through
most of the cases that produces localized messages. Since a Selenium
test is client side, though, it cannot (re)produce all the errors
on a server. So, for example, a missing connection to a database
could not be triggered. Another thing we might have to consider is
how to set breakpoints to pause the Selenium test in order to allow
a translator to check the messages.
That would be wonderful. (I don't think PHPUnit is the way to go,
since translators would only get checks whether message looks
like it *should*, not the context).
When translating a complex extension, like FlaggedRevs or AbuseFilter
you have to develop quite a large dictionary of concepts that should
be somehow consistent. This attempt at consitency somehow leads to unclear
messages as seen in the real life.
So having a possibility to have a pre-flight test of the translation
(or even watch the demo of the original in action) is something
Selenium could deinitely help. In many cases, translators
do not have permission to experience some interface in the live
environment (CheckUser, AbuseFilter, etc.). Could Selenium
solve this problem as well? Is it just mocking up the interface
or do I need a instance behind that is somehow setup somewhere?
//Marcin