i18n UI messages, and start showing explanations for rules from the old checker

[tripu]

Changes, in a nutshell (a large nutshell):

• The same UI messages that were in l10n.js are now duplicated in two languages: l10n-en_GB.js and l10n-es_ES.js.
• …which are identical right now (both are in English), except for the values of these two keys: heuristic.group.candidate and heuristic.group.not-found, which are translated into Spanish (for testing purposes).
• Added a field lang to the general configuration in validator.js (set to en_GB).
• Tweaked slightly @deniak's rules.json so that now, instead of being a huge array, it's a huge object. And the IDs of profiles (WD, REC, etc) are the keys in that object.
• …and that is to be able to maintain a new file of selectors, l10n-selectors.js. This file associates each ID of a user message (the same we have in l10n-en_GB.js) with the JS selector that will retrieve the user-friendly, verbose description of a rule. These selectors are applied to rules.json calling eval() (yes, eval()!). These user-friendly descriptions are the ones you see in the old pubrules checker.
• And this new verbose explanation about a rule is shown in Specberus' UI now.
• Added 3 new tests to make sure that all values in l10n-selectors.js resolve correctly to strings in rules.json. This is to make the whole thing a bit more robust — writing selectors like this, and passing them along to eval() would be error-prone otherwise.

Work that is pending, and improvements:

• @deniak's program to generate rules.json ideally should produce this version (a large object, instead of a large array).
• Continue writing selectors for all rules (there are only 6 now).
• At some point, translate messages to other languages? (this isn't even discussed, and has no priority whatsoever at the moment).
• Switching between different languages (if ever we support several) should be done on the UI, by the user (not hard-coding the locale in validator.js).
• Get rid of eval(); do it better.
• Right now, l10n-selectors.js assumes that the profile is WD. When we start supporting other types of docs in Echidna, we'll have to refactor this, so that the profile is a parameter.
• Come up with a better way to maintain rules, selectors and messages!

[tripu]

@deniak, assigning to you because at least you saw the beginning of this work weeks ago. I know I haven't done a good job at explaining the changes, so please ask me about this. And if you can think of simpler, safer ways to do this, let me know too!

[astorije]

@tripu, that's a lot of commits up there. Did you mess something up on your local copy? You probably don't want to have all of them merged and squash some of them before merging.

[deniak]

+1 to squash the commits

[astorije]

Hum, the fact that an old commit of mine (aka already in master) appears in this PR is very likely (in my understanding) to ask to rewrite the history in master :-/

[astorije]

I'm a bit unclear: does this PR add any feature? Spanish support, even if poor, seems one. If so, maybe this should have triggered version 1.1.0 instead of 1.0.2 but I agree it's borderline here.

That said... urgh to eval() indeed! I didn't think this PR would make it to master until it's being removed :-(

[tripu]

@astorije:

Having these two messages in Spanish serves mainly as a test to prove that the new i18n feature works. i18n is a byproduct of the refactoring I've done here. Actually translating the tool is not something I intend to do any time soon…

The actual feature is that we can start showing detailed, formatted descriptions for rules (exactly the same texts you see in the old pubrules checker) by simply filling in all the selectors in lib/l10n-selectors.js. Because most of those selectors still need to be written, I wouldn't consider this even a “minor” change yet — once they're all there, we can increase the minor, sure.

Finally, those selectors are the reason I'm using eval(). Sure, it's bad practice. I'd like to find a more elegant way to maintain rules and descriptions, and match ones against the others. That being said, eval() here is being used in a very specific context, and I certainly can live with it.