i18n support via new keywords "defaultLocale", "locales", and "locale…

[brettz9]

…Key"

This was similar to my earlier proposal with the section at https://github.com/json-schema/json-schema/wiki/multilingual-meta-data-%28v5-proposal%29#concerns (and which has some examples).

[brettz9]

I plan to amend this update relatively soon to include a more comprehensive approach.

[awwright]

Can you describe some specific use cases? I haven't ever run into needing this, so that would be helpful.

Let's also compare how other technologies tackle this. https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-03 just says you can use whatever is negotiated by HTTP, but I don't find this solution very good because unlike XML or HTML, JSON does not have any way to indicate the language of the rest of the document.

The one reason I don't see this as a good idea is right now, strings aren't intended to be seen/consumed by end users. More specifically, if you want to add a translation, you have to change the schema, this is frequently neither desirable nor possible, using the application's builtin localization to translate strings tends to be the preferred solution that I've seen.

[brettz9]

Thank you for your response and specific feedback.

As far as use cases:

1. JSON Editor is a tool allowing for the convenient editing of JSON content which builds HTML forms in a JSON Schema-aware manner. Having i18n for JSON Schema would allow i18n of the form labels without the need for maintaining separate copies of schemas. A viewing (as opposed to editing) tool which was similarly type-aware could take advantage of such i18n as well (e.g., to have a default way for displaying any JSON based on its schema, e.g., showing date content within a calendar or making URLs clickable without the need for custom templates).
2. A generic table browsing tool may allow conveniently declarative specification of available columns and their types. My interest in this is for multilinear texts, such as displaying scholarly notes alongside particular paragraphs or verses, but providing a localizable interface, e.g., to present a range selection for integer columns indicating paragraph numbers and pull-downs for choosing. You can see this generic JSON-driven texbrowser in action at http://brettz9.bitbucket.org/ (though the final page displaying the table results is not yet implemented, you can at least see how the special-purpose i18nized form is generated).

More later, but maybe you could clarify what you mean about strings not intending to be seen/consumed (besides your specific example). Do you mean strings from JSON Schema? Do you mean for JSON documents served in whole?

[awwright]

I don't think we can actually have the spec say that we can assume a particular language. It's one thing to use largely english words for the vocabulary (at the end of the day, it's just an arbitrary term), it's another to say "assume a default locale of 'en'".

I'll close this out but hopefully we can discuss i18n in another issue.