so we know what is in use for this game session.
What is that useful for? The game supplies text in the player's chosen language, and the player's programs display that text as-is. Why would they care which language it is?
so we know what is in use for this game session.
Yeah, but JUST for the star descriptions and other "custom" texts (I am writing this just for the case I was misunderstood). For the system securities, governments, etc. translations (simply the "type definitions") I think it is better to has it outside the log completely. But if it will be simpler to create, I am OK with the "Economy_Localised" and the language identifier in the "Headings" solution.Discussing with Artie and others on discord, maybe have a static file for the common elements (UI, ship events, etc.), and have specific translation entries in the log for dynamic events, such as star descriptions. This avoids large static files, and prevents spoilers from dynamic content.
The language tag should be ISO 3166 and language code should be ISO 639. So something like this:
I agreed on this, that would be very helpful. There are many tools and libraries available that work with standardized codes.... The language tag should be ISO 3166 and language code should be ISO 639...
Really, the version hchalkley proposed is the simplest way to do it, both for the game writing the logs, and anyone wanting to read them. The only thing I'd see as an improvement there is changing e.g. "Economy_French" to "Economy_Localised", and then anything reading it wouldn't need to look for these values, or even know which language the player is using.
As these localised values would only be relevant for local display (the $whatever; things should be parsed/stored/uploaded instead), just showing any _Localised directly to the player should be fine. Websites wanting to display the localised text should have no problems gathering the translations with the help of users.
One more nugget of feedback
Can 5.4 Died be renamed to DiedWing? I intended to use the category names as dictionary keys, and this will cause 5.4 Died to overwrite 5.3 Died![]()
Currently the Companion API lags game events. Typically the lag is less than a second, but sometimes can be much more. I don't see anything in the proposal about changing the Companion API, so don't expect this to change.And a question on synchronisation: if I receive (for example) a "ShipyardBuy" event can I query the companion app API safe in the knowledge that it will give me the data on the new ship, or might there be a delay between seeing the event and the server being updated?
This could actually be useful: if "event" is the only lowercase one (as it isn't a property of an actual event), that's a half-decent way of avoiding any possible collisions - it's not actually a key on the event, it's telling you what it is. Timestamp would potentially also fall into this category.One small part of feedback I have: why are some of the event records keys lowercase and some uppercase? One example, from 3.1, ClearSavedGame:
That's a very good idea; +1 for having the format be consistent between the two, just only populated with one entry if it's not a wing.5.3 should be dropped. It can be replaced with 5.4 having a single entry in each array.