Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localization and standardization of error messages #4

Open
clux opened this issue Dec 12, 2012 · 2 comments
Open

Localization and standardization of error messages #4

clux opened this issue Dec 12, 2012 · 2 comments

Comments

@clux
Copy link
Collaborator

clux commented Dec 12, 2012

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
Copy link

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
Copy link
Collaborator Author

clux commented Sep 22, 2013

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.

@clux clux removed this from the 1.0.0 milestone Sep 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants