Needs to discuss design for i18n (internationalization / translations) and l10n

[brierjon]

Currently the schema is largely in English and the metadata entries also are in a single native language of entry. Given some need to implement multiple languages for descriptions and a few other fields we should discuss how we should store, facilitate collaborative translations, and track changes. There are schema to look at for JSON handling of i18n and i10n.

Possible points to consider:

1. Indicate the initial entry and authority to be translated from.
2. Indicate requests for translations so any site can expose:
   i. their own priority of projects for translation and to what language(s)
   ii. other implementation's projects for translation and to what language(s).
3. Method for translation? Use of central translation platform vs developing distributed consensus of a translation.
4. Other considerations?

Getting this discussion primed for the next discussion since I'll be working on a dual language implementation and we'll need support for multiple languages.

[pbrenton]

Good point Jonathan. There is an attribute in the schema for encoding language(s) as part of the project-level core terms (term = language, see below). This would apply in implementations of it, but it is certainly true that the schema itself is currently only written in english.

{
"name": "language",
"description": "The encoding language used for the project. Uses Unicode Standard UTF-8 (ISO/IEC 10646:2014 plus Amendment 1).",
"required": true,
"allowMultiple": false,
"owl2ObjectType": "property",
"dataType": "text",
"synonymTerms": [
{
"nameOfStandard": "Dublin Core",
"namespace": "http://purl.org/dc/terms/language",
"property": "language"
},
{
"nameOfStandard": "ISO 19115",
"namespace": "ISO",
"property": "MD_DataIdentification.characterSet"
}
]
},