>> Markus Glaser <gla...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
