Separate language strings. Fixes #111.

[jindrichmynarz]

I've separated the language strings to defaults.js, so that they are exposed as yasqe.options.language and can be thus overwritten by different locale in the YASQE constructor. I've also fixed a couple of typos, such as "Fetchting autocompletions" in autocompletes.utils.js.

This is just a proposal of how localization can be introduced in YASQE. Please advise if there is another preferred way to do so.

[LaurensRietveld]

I got the feeling this might be a bigger issue than expected if done right.

• a locale setting (default 'en', or null/undefined for using the browser's locale)
• A way to add the translated string to the options (e.g. options.language.en) object (either via ajax request, or as part of the settings)
• Adding a function for getting all ui-related strings. Something like yasqe._('This line is invalid. Expected:'), where the english translation is the key we'd use for other translations (probably wont cover all use cases/languages, but it'll probably suffice)
• Applying the locale setting to the YASR output plugins. I see most plugins have a localization system in place. The implementation is not consistent between these plugins though, so this requires some tweaking as well
• (optional): check whether a locale is supported by a plugin, and show in english if it's not.

This isnt on my priority list atm as there are a few other YASGUI issues I need to take a stab at. But, if you'd like to take this up, that'd be much appreciated.

[LaurensRietveld]

Closing due to inactivity. Still open to the idea though, but just not at the top of the todo list atm