The problem I observed was this:
0. install Fedora while being connected to internet
1. in the initial language selection preselected by some heuristic
based likely on geoip, observe you have everything in language
A different from English; A is also preselected and subsequently
confirmed by the user
2. realize you actually want a different language (English), go "back"
(almost identically looking Language Support dialog) choose English
a. previously selected language A cannot be deselected
b. when confirmed with English added, the dialog strings are still
in language A
My suggestion is that the functionality of the very initial language
support selection and subsequent dialog to adjust the preferences
for that should be functionally equivalent, not that the former is
binding and the latter is just additive.
FWIW, it reminds me a really bad design of installer of "the other
operating system" where a mistake in initial language selection seemed
even more fatal, while here, the remedy is simply a reboot.
Which is still anoying enough (for me) and hence this bug report.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
IIRC this is at least partially caused by GTK not being to switch translation language at runtime. We do some nasty hacks to do change it for the language selection screen and it is basically impossible to do once all the screens and widgets have been loaded.
There is a chance GTK has improved since as it's some time since we last looked into this.
I don't know the exact limitations, but a generic possibility
not relying on the UI toolkit might be like:
1. serialize current state (if suitable)
2. exec the program anew or spawn a new instance in parallel,
graphically overlying the original
3. in the new program instance, deserialize the state from 1.
4. terminate the old instance from 2. if running in parallel
*** This bug has been marked as a duplicate of bug 1300148 ***