i17n support (custom error messages)

[conao3]

Thanks for that great crate!

I want to use this crate via Python but this module lacks i17n support so I should try parse English and translate into Japanese.
I believe this support make this more end user friendly.

[Stranger6667]

Hi! Sorry for the delayed response. I like the idea but I don’t know what would be the best way to provide the possibility to choose the language without runtime overhead, so this feature is zero cost

[bublikOff]

I do also use Json schemas in my PHP projects and I have samthing like that

{
    "type": "object",
    "properties":  
    {
        "partnerid": 
        {
            "type": "string",
            "format": "guid",
            "formatError": "Partner id has wrong format"
        },
        "status": 
        {
            "type": "string",
            "minLength": 1,
            "minLengthError": "Status can not be empty"
        }
}

And my data gateway returns property path and error for it. So the app can use path to find correct UI element and show appropriate error message along to this UI element
The main benefit from custom error messages, instead of standard ugly and non informative (for end user) ... is that I do not need to implement extra functionality that will translate errors from JsonSchema to errors that can informative for end user and for developer only.

PS
For the moment I do use this

pub fn json_get_by_path<'a> (value: &'a serde_json::Value, path: &'a str) -> Option<&'a serde_json::Value> {

    let path_segments: Vec<&str> = path.split('/').collect();
    let mut current_value = value;

    for segment in path_segments {
        match current_value.get(segment) {
            Some(next_value) => {
                current_value = next_value;
            }
            None => {
                return None; // Property not found
            }
        }
    }

    Some(current_value)
}

if let Some(custom_error_message) = json_get_by_path(&schema, format!("{}Error", error.schema_path.to_string().replacen("/", "", 1)).as_str()) {
                error_message = custom_error_message.to_string();
}

It search for custom defined errors in schema. For eg "formatError" or "minLengthError" and etc

So ... you can use multiple json schemas for each language and each language will have custom defined error messages

[jpmckinney]

My approach, from using python-jsonschema, is essentially to do post-processing on the ValidationError instances generated by iter_errors. I write my own translatable strings for each keyword; these strings contain placeholders and are translated using gettext. I then substitute values from the ValidationError into the placeholders.

To support that approach, I created #650.

Thinking of other options: Right now, the fmt::Display implementation for ValidationError already has format strings for all keywords. Perhaps these can be exposed (as read only) via the API. A user is then able to read and translate these format strings (using whatever tools they prefer). Finally, a new option can be added to initializers to accept a mapping of error type to format string, to override the default.

This second option is fine if you are satisfied with the default strings and just want to be able to translate them. It is less work that having to fill in placeholders like in the first option.

Both options can be pursued for the different needs.

[jpmckinney]

For the second option:

Rereading the fmt::Display implementation, I see that there needs to be pluralization handling. Considering how complex pluralization is across languages (one, two, few, many, other in Arabic), I think it’d be best if this crate implemented i18n itself (eg with gettext) and people could contribute translations to new languages.

My original “second option” above wouldn’t work due to the need for pluralization support (the min… and max… keywords).

[Stranger6667]

Hm, at first glance exposing kind + context (e.g. limits) looks like enough to build any translation. But a feature-gated built-in i18n support would be indeed super useful.

This way anybody can either use a built-in translation or build their own. I agree with your comments above :)

The first step could be just exposing extra context.