Add value and details to i18n available interpolations

[stephenprater]

The default errors include helpful information in the errors key. For instance a Minimum validation like

"employee_count": {
        "type": "integer",
        "minimum": 1
}

might include

"error": "number at /count is less than 1"

In the detailed error return.

Unfortunately - the values used to produce this string are not all available in the translation layer.

For keywords that produce error messages, the "default" error message is defined in the class itself - where it has access to the keywords value property and details passed into the error method. Several of the default errors take advantage of these variables to expose richer error information.

In order to produce error messages of the same informativeness as the "default" message while taking advantage of the I18n layer - this PR exposes the value and details property of the keyword object that is already in scope when i18n is called - this allows us to for instance translate the above error in the PigLatin locale to:

"error": "umbernay atyay /count isyay esslay anthay 1"

using i18n - rather than being limited to

"error": "umbernay atyay /count isyaya esslay anthay ethay inimumay"

[davishmcclurg]

Hi @stephenprater—thanks for opening this! Seems reasonable to me. How does i18n handle hash variables (details)?

Is there a way to do this for x-error as well? Might have to flatten details somehow:

json_schemer/lib/json_schemer/result.rb

Lines 34 to 39 in 51f2266

	@error = source.x_error.gsub(
	X_ERROR_REGEX,
	'%{instance}' => instance,
	'%{instanceLocation}' => Location.resolve(instance_location),
	'%{keywordLocation}' => Location.resolve(keyword_location),
	'%{absoluteKeywordLocation}' => source.absolute_keyword_location

[stephenprater]

Hi @davishmcclurg - in general the I18N gem doesn't translate interpolation values - so it just presents the stringified version of the details string. ({ 'missing_keys' => ['foo'] } in practice, as I couldn't find any use-cases of the details variable other than in the required keyword. I flattened it down to a comma separate string so you can interpolated it into a string - and it becomes missing_keys: key1, key2 - it doesn't appear that there's another "out of the box" use of this variable.

I also added the same two interpolations to the x-error output - although there the details variable I left as a hash.

Concievably, we could translate the details variable in another pass through the I18N system (it would have to be a separate call from the main translation and I'm not sure if custom details are populated by other keywords or not.)