Invalid ReadAlong XML when translations are added

[sergeleger]

The translation sentence (<s />) elements have the same id value as the original sentence. See id="t0b0d0p0s0" in the following example. This violates the XML specification requiring id attributes to be unique across a single document.

<p id="t0b0d0p0">
   <s id="t0b0d0p0s0"><w id="t0b0d0p0s0w0" ARPABET="T HH IY S" time="0.72" dur="0.25">This</w> <w id="t0b0d0p0s0w1" ARPABET="IY S" time="0.97" dur="0.14">is</w> <w id="t0b0d0p0s0w2" ARPABET="AA" time="1.11" dur="0.05">a</w> <w id="t0b0d0p0s0w3" ARPABET="T EY S T" time="1.16" dur="0.58">test</w>.</s>
   <s do-not-align="true" id="t0b0d0p0s0" sentence-id="t0b0d0p0s0" class="sentence__translation editable__translation" xml:lang="eng">Ceci est un test.</s>
</p>

There was an attempt to fix this issue, but there is now functionality that depends on this broken implementation. Additionally, any corrective action will need to support the "broken" implementation since older readalong XML files will not get fixed.

Recommendations

• append the suffix trN to the original sentence's id to generate t0b0d0p0s0tr0. Current read alongs have a single translation, the trN prefix would support additional translations.
• use the sentence-id attribute to identify a sentence's translation
• maintain current implementations to support older read along files.

[sergeleger]

In readalong cli, anN is used instead for "annotation".

[joanise]

In readalong cli, anN is used instead for "annotation".

There is a concept of annotations which can be distinct from translations. In a PR we had to roll back (due to breaking other stuff) Del implemented an option to have multiple annotation layers as an alternative to translations. Linguists keep asking for this to put their interlinear annotations (e.g., glosses, lemmatization, morphemes, translations, phonetic transcription, etc) into readalongs.

We had these annotations for a short while, but then we had to roll back the Studio-Web. We since re-applied/re-implemented all the other rolled back features, but not this one, as it's the hardest one to redo.

All this to say, there's a question to resolve: we might want "trN" for translations, and reserve "anN" to the alternative annotations. But it would also be fine to use "anN" consistently everywhere for both, since translations are the most frequently used annotation layer. @deltork ?