This is the intended behaviour if English is your native text, as “translations” of the native text are treated as copy-edits of the source text for all foreign cultures (for cases where you need to update your source text but can’t access the source text itself, such as when importing copy-edited dialogue lines).
If you intended to make this change to make an en-GB translation, then you should add a separate en-GB culture and translate “Apartment” to “Flat” in there.
As an aside, I’d just like to make sure you’re not hand-editing your archive files. They’re not really designed for that, and we’re likely going to making some changes in a future version that will affect how they work (gathering will no longer update the entries, only a PO import will). You should really always export to PO to edit, and import from PO to get your changes back (although you’ll likely get away with tweaking an existing archive entry).
If this is intended, then how you do you do minor grammar or typo corrections for English, without affecting all other languages and having to redo all the other translations?
Apartment and Flat was just an arbitrary example of changing the english (native) loca, unrelated to en-GB.
The edit from Apartment->Apartment to Apartment->Flat was done in the Localization Dashboard. Will the Localization Dashboard remain an intended place to edit localization, besides importing and exporting .po files?
So to summarize:
We have the 4 levels: key → source_text → native_translation → other_translation.
In the English (native) .archive, key plays no role, since it only contains source_text → native_translation.
In the Spanish .archive, key and source_text play no role, since it only contains native_translation → other_translation.
source_text is actually not used as a common source for all languages, just once during the creation of the English Loca.
How you do you do minor grammar or typo corrections for English, without affecting all other languages and having to redo all the other translations?
You currently can’t, as the archives are keyed using a “namespace + native string” pair, so once you change the native string, the association is lost.
We’re planning to change this, hopefully for 4.13 but maybe for 4.14 depending on time, to be keyed using a “namespace + key” pair. This would allow you to tweak the native text but still use a “stale” translation (loading “stale” translations would be disabled by default, but could be enabled using a config option).
Will the Localization Dashboard remain an intended place to edit localization
The Translation Editor in UE4 (which is actually a separate tool from the Localization Dashboard) has never been the intended primary place for you to edit your game translations.
It should only really be used by localisation QA to make a spot fix, as it’s a very simple tool lacking many features you would actually want from a translation editor (and we currently have no plans to ever implement these features).
We always recommend you translate your game via a more competent tool that contain things like a translation memory - if you need a collaborative solution for this then we use OneSky as our UE4 localisation provider (UAT and the editor can interact with OneSky), and if you’re looking for a local solution then POEdit works well.
Just in case this helps, I found a way around this myself. We made the native culture in the localization export from en to a subset of en (I choose the wonderful Pitcairn Island en-PN) and made the loc for that the exact default that the game exported.
Then we could safely edit the en localization po’s and no worry about breaking localization everywhere else.
A few people have taken this approach, although they used en-US-POSIX which is a machine culture that no-one will ever actually use (unfortunately it wasn’t exposed to the localization dashboards list of cultures until 4.13).
Especially interesting are the cases with whole sentences:
key: 04F46D4746BB210F71622E806020D65D + some path
source-text: KEY_BUILDING_LIVING_DESC
fake/native-English: KEY_BUILDING_LIVING_DESC
visible-English-US: People can live here.
visible-English-UK: Peasants can live here.
visible-Spanish: Las personas pueden vivir aquí.
otherwise we would have:
key: 04F46D4746BB210F71622E806020D65D + some path
source-text: Dudes can live here. (dummy sentence by coder, which created identical fake/native English)
fake/native-English: Dudes can live here. (dummy sentence by coder)
visible-English-US: People can live here. (final refined English by translator)
visible-English-UK: Peasants can live here. (final refined English by translator)
visible-Spanish: Las personas pueden vivir aquí. (final refined Spanish by translator)
We actually took the approach of using traditional key like text in our game, as game concepts etc change names so much. So with this change it was very much like you first two examples.
