tournament-js / tournament

A tournament base class for static tournament types
MIT License
64 stars 13 forks source link

Localization and standardization of error messages #4

Open clux opened 11 years ago

clux commented 11 years ago

At the moment all the ::unscorable and .invalid functions return hardcoded strings for the different error cases. I don't throw for these because it's likely just hard to configure the parameters right so that everything is consistent and therefore just try to provide helpful messages for the app to pass up to the user (if tournament is presented via a web interface for instance).

Most of these strings require no interpolation (and can probably part with this entirely), so for localization purposes it should be possible to just stash them in a config somewhere.

The two things I'm unsure about: should messages be interpolated with expected parameters (such as match.p.length to indicate how long the scores array really needs to be) via util.format and then just stored somewhere as "Need to have at least %d scores" and expect it to be interpolated, or should the error message be so generic that it can be a constant so the app can test against specific reasons like an ENUM?

Secondly, are the error messages actually good now? Can they be standardized more across the tournament types so that they can be reused etc? Some more pairs of eyes on this bit would be helpful :)

llafuente commented 11 years ago

You should emit those errors, warnings

in fact I would do

var t = new Duel(); t.init(); // throw if nobody listen error event, same as node.

Hard change, broke compatibility, but just need to add one line..

clux commented 11 years ago

That's not ideal. Having the message come back in a different function to the one that was denied scoring/creating forces the app to do book-keeping on which instance the error came from.