Potential guidelines to deal with source terms for new translations in case of proofreading/terminology review based on new evidence when compiling multilingual terminology. about hxltm

[fititnt]

RFC 6497, https://datatracker.ietf.org/doc/html/rfc6497
BCP 47 Extension T - Transformed Content

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification.

Either for potential initiatives like TICO-19 (who, based on all explanations they mentioned about using more than one source language, so an expressive way to store also wich source language or exact what translation was used as source for new versions) but also for ad hoc variants of source term, something like RFC 6497 can be relevant. It may not be as easy to make transparent for users, but do exist some expressive way to explain the source of a language.

  For example:
   +---------------------+---------------------------------------------+
   | Language Tag        | Description                                 |
   +---------------------+---------------------------------------------+
   | ja-t-it             | The content is Japanese, transformed from   |
   |                     | Italian.                                    |
   | ja-Kana-t-it        | The content is Japanese Katakana,           |
   |                     | transformed from Italian.                   |
   | und-Latn-t-und-cyrl | The content is in the Latin script,         |
   |                     | transformed from the Cyrillic script.       |
   +---------------------+---------------------------------------------+

On our case, one translation to Spanish from English (when really want to make sure what the source was) would be spa-Latn-t-eng-Latn, but if it was eng-Latn-x-term1234, the variant would be spa-Latn-t-eng-Latn-x-term1234. There is also the possibility of translations of translations, and depending of the route, this could means different target translation.

There are some corner cases, but since potential proofreading/review is likely to be only from part of terms, some way to track what where the source terms could be relevant. So for example, if later was found that the proposed term was not good, only that part of translation could be invalidated. Another reason is the case of potentially allow export for translation both versions not as text annotation (an XLIFF comment) but two different translations from humans, but this situation is so specific, that instead of creating a new column, who is preparing translations could manually copy and paste the entire concept, and use a different concept code.

I understand that this level of keep track on how terms are generated are overly technical, but since HXLTM (as spreadsheet-like, not the TBX, wich could keep track of more data, but is less supported by tools) already need to be self-sufficient without need of complex frontends, the care on how to label the codes could be much better than most tools already encode terms.

Also, I'm almost sure that even the TBX validator (https://www.tbxinfo.net/tbx-dialects/?id=4) could consider as invalid language the BCP47 language style of Extension T, so if even validator don't have such feature, is very unlikely that other tools would support this compact notation.