Translations import/exports in XLIFF, JSON, simple CSV or something ?

[Tony Li]

I'll look into this for the next official update of the integration.

If you're modifying the integration, you could skip Group / Group Display Name when going through the fields, and just accumulate them in a HashSet<string> so you have a list of unique group names. Then add that each of those group names to the Localization Package string table.

[NotVeryProfessional]

Yes, but writing it back can be tricky. I'll need that same table, so I must delay importing conversation entries until I do or go over them twice. I'm trying to think of a smarter way.

[Tony Li]

Am I not thinking of something? When you read it back, each quest that has the same shared Group or Group Display Name will read from the same entry in the String Table. So it should be fine.

[NotVeryProfessional]

I might be wrong, but:

When exporting, the hash table is built while writing out the entries. Only at the end is the hash table added. So in the exported file, it is after the entries.

When reading the (translated) file back, the entries are read first, at which time the hash table has not yet been read.

Plus if I import the file into a translation software (weblate in my case), translate it and then export it again, I can not guarantee that the order of entries is unchanged. So I can't be sure the translated group names are read before being used for the first time.

Ah well, I think just scanning the file twice is not an issue and faster implemented than coming up with some convoluted solution.

[Tony Li]

When reading it back into the dialogue database, the integration doesn't care about the order of the entries in the Localization Package string table. So it should be fine. However, if you want to read it in two stages, that shouldn't be a problem. It should be fast enough that it's not a concern.