Multilang: client metadata editor i18n

[etj]

We need a way to pack multilang entries in a visual control that makes it clear that the various text fields belong to a single context.

On client side, we may take example from how GeoNetwork deals with multilang translations.

• In this case, "English" is selected:
  
• Clicking on other languages, the related translation is shown:
  
• Clicking on "all", all the translations are presented at once:
  
• By selecting "One" you get back to the single language textfield.

As reported in #13642 , this is the jsonschema related to a multilang field:

    "title": {
      "type": "string",
      "title": "Title",
      "description": "name by which the cited resource is known",
      "maxLength": 255,
      "geonode:handler": "base",
      "geonode:required": true,
      "geonode:multilang": true,

      "ui:widget": "hidden"
    },
    "title_multilang_en": {
      "type": "string",
      "title": "Title [English]",
      "description": "name by which the cited resource is known",
      "maxLength": 255,
      "geonode:handler": "sparse",

      "geonode:multilang-lang": "en",
      "geonode:multilang-group": "title",
    },
    "title_multilang_it": {
      "type": "string",
      "title": "Titolo [Italiano]",
      "description": "nome attraverso cui la risorsa citata è conosciuta",
      "maxLength": 255,
      "geonode:handler": "sparse",

      "geonode:multilang-lang": "it",
      "geonode:multilang-group": "title",
    },

• "geonode:multilang": true in title tells that this is the main entry, to which the other entries will reference.
  • This is needed server-side.
• "geonode:multilang-group":"title" tells to which main entry the subschema is referring to, useful for grouping translation subschemas. Having this explicit info, the client does not need to make assumptions about which fields belong to the translation group using the fieldname or whatever.
  • this is just a proposal
  • is it useful for the client?
• "geonode:multilang-lang": "it" tells the client to which language this entry refers.
  • this is just a proposal
  • is it useful for the client?

See also:

• Multilang: metadata manager i18n #13642

[giohappy]

It's important to highlight that ANY field can be configured to have multilang support, and multilang support is optional for ANY field. So the implementation must abstract from the specific fields in these examples.

In this moment the metadata editor shows the following layout:

[etj]

Not any field, but only fields that have "type": "string",
Also, at the moment only root fields, not nested fields (i.e. string fields within "type": "objects" fields)