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.
Translations import/exports in XLIFF, JSON, simple CSV or something ?
-
- Posts: 150
- Joined: Mon Nov 23, 2020 6:35 am
Re: Translations import/exports in XLIFF, JSON, simple CSV or something ?
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.
Re: Translations import/exports in XLIFF, JSON, simple CSV or something ?
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.
-
- Posts: 150
- Joined: Mon Nov 23, 2020 6:35 am
Re: Translations import/exports in XLIFF, JSON, simple CSV or something ?
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.
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.
Re: Translations import/exports in XLIFF, JSON, simple CSV or something ?
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.