Should we add `translated-title` and `transliterated-title` to the objectified title?

As a follow-up on converting titles into objects, I think we should discuss whether there is any value in adding alternate forms (translated or transliterated title forms) to these title objects. Maybe so:

title:
  main: "Война и миръ"
alternate:
  - main: "War and peace"
    type:  "translated"
  - main: "Vojna i mir"
    type: "transliteration"

Or just so:

title:
  main: "Война и миръ"
  translated:
    main: "War and peace"
  transliterated:
    main: "Vojna i mir"

[bwiernik]

The BCP 47/RFC 5646 scheme Frank linked to defines languages codes unambiguously not only for languages/locales but also for scripts and the like. It’s summarized here. The basic structure is language-script-region, with each part following defined patterns.

For example, if an item with language: ru contains a language-alternate element with language: ru-Latn, that means it’s a romanized transliteration of the title. A language-alternate element with language: en would mean an English translation of the the title.

[fbennett]

@fbennett Why is it that you have two multi objects in your CSL JSON export, one under author, and the other as a top level object containing standard variables? What’s the reason for this? Is this better than just having one multi object at the top? Or one multi object under each variable?

The aim was (and is) to maintain compatibility with CSL-JSON to the extent possible. Ordinary fields are strings, so it’s not possible to give them a sub-field without changing the data type. Creator variables are already objects, so a subfield can be added without changing the data type; and since creator fields are dynamic, it makes sense to tie the variants to each name instance—and CSLm-JSON just reflects that structure, which keeps exports simple.