TranslationsConfigFields
Handles loading and accessing translations from a per-language CSV file. Each language has its own CSV with format: "key","en","" Example: french.csv has columns "key","en","fr"
How a corrected English default reaches an already-translated server The live CSV alone cannot answer the only question that matters when the plugin ships corrected text: did the shipped default change, or did a human deliberately write this? Both look identical on disk. Before this was tracked, add simply refused to touch any key that already had an en value, so a server running French kept the original wrong English - and the translation derived from it - forever.
The reference point is persisted in a sidecar CSV, <language>_data.csv, with the same schema as the live file. For every key it records the pair the live row was last reconciled against:
en- the shipped English default the stored row was derived from.<lang_code>- the translation that was present at that same moment.
<language>.csv, because the live file is a published artifact: it is downloaded verbatim from magmaguy.com/api/elitemobs_translations/<language>.csv and edited by translators in spreadsheet software. TranslationCsvParser.TranslationData also models every column after the key as a language, so a baseline column would be a fake language that getLanguages would happily hand to player-facing lookups. The sidecar keeps the published schema untouched, is already excluded from the /em language listing, and a missing one is a well defined state rather than a parse error. Ownership The en column is plugin-owned reference data: on a translated server it is only ever displayed when the language cell is blank, so it is the shipped default's mirror, not a place anyone edits to change what players see. The <lang_code> column is human-owned. Reconciliation therefore never writes the language column of an existing row - it only ever refreshes en, and reports how many translations were left pointing at English text that has since changed.