Interkarma wrote: ↑Tue Feb 02, 2021 2:00 am
Region names are hardcoded and immutable. There are methods that search for locations by name using strings for both region and location, so we need to be careful with this. While researching feasibility during initial localization rollout, I decided best not to touch region names for now. Region names are proper (fantasy) nouns in any case, and shouldn't require translation. There's a strong chance they will not enter localization.
I'm not talking about renaming regions. I'm talking about the RegionName parameter on the 4th line of a location override. That said, now that I think about it, I'm not sure what the game would use this piece of data for in the first place. The region a location is found in is determined by the 3 character extension attached to the 4 MAPS.BSA records of each region. And according to the UESP, this parameter doesn't appear to be present in the original data. So is this just added by DFU for identification purposes?
Interkarma wrote: ↑Tue Feb 02, 2021 2:00 am
The latitude/longitude are integral to world indexing, this would lean more into adding new locations or moving locations than just replacing existing data. I don't feel this is something I'd want to support without serious review, if ever.
Okay, if it's not possible to move locations around then indeed, it makes no sense to support this on the travel map.
Interkarma wrote: ↑Tue Feb 02, 2021 2:00 am
However, locations might require translated names, or even just corrections like fixing "THe Crypts of Rhajom". I'm still considering how location names will be supported in localization framework, and how this will interact with world data replacements.
Bethesda's approach for Skyrim (and presumably Fallout 4) was to configure any user-facing strings in the game such that the data was not stored in the ESM/P but in STRINGS files that are different for each language. Similar to what you appear to be doing here. However, when a modder creates a mod that touches any of these strings, the link from the plugin data to those STRINGS is broken and the mod will set those strings to whatever they are for that modder's language. The modder can counteract this by creating their own STRINGS files for their mod's strings and provide their own translations.
Perhaps you could take a similar approach: Have WorldData overrides overwrite any localised strings DFU sets and make it the modder's responsibility to provide translations of their mods. You might then be able to provide a way of, say, letting players provide an INI, JSON or something with their mod that contains translated strings and then provide a way to define links to those translated entries in their WorldData overrides, scripts and whatever else.