When installing from a Fedora 22 live image and selecting a language other than English on the Welcome screen, several strings for which translations are available are not translated. For instance, on the main hub, the titles of spokes and the hub 'sections' (LOCALIZATION, SYSTEM) are not translated. Neither are most of the spoke 'status' texts ("Automatic partitioning selected" etc). Attaching screenshots of the main hub in F21 and F22 Beta TC8 Workstation live images, after selecting French on the Welcome screen. Proposing as a Final blocker: https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Installer_translations - "The installer must correctly display all sufficiently complete translations available for use."
Created attachment 1011852 [details] Fedora 21 French live install hub screenshot
Created attachment 1011853 [details] Fedora 22 French live install hub screenshot
Yeah it's because LC_ALL isn't being reset, and python's gettext functions use LC_ALL and LC_MESSAGES before checking LANG. The strings that do end up being translated are the ones going through gtk, because the C version of gettext uses the locale. Localization is kind of the worst.
What changed from F21, out of curiosity? I should probably note here that in touching anything to do with this, we're going to want to be careful we don't cause https://bugzilla.redhat.com/show_bug.cgi?id=1169019 (the actual UnicodeDecodeError, not the zillion "'NoneType' object has no attribute 'path'" traces libreport thinks are dupes for some bizarre reason) to start happening again - that doesn't seem to be affecting F22 so far.
(In reply to awilliam from comment #4) > What changed from F21, out of curiosity? https://github.com/rhinstaller/anaconda/commit/4d686f1e7aecde1d17ee13da86e84298da88887c
Ah. So we've actually been here before: https://bugzilla.redhat.com/show_bug.cgi?id=1169019#c30 https://bugzilla.redhat.com/show_bug.cgi?id=1169019#c31 and for F21 we didn't accept the LC_ALL 'fix' - but it got committed to master, apparently. Of course, if we take it out, we'll probably start getting UnicodeDecodeError crashes again. But still, it's clearly not the right thing to do.
FWIW, as bcl is still opposed to the reload(sys); sys.setdefaultencoding('utf-8') hack, I thought I'd do some digging into why pyparted 3.10 triggered this whole mess in the first place. So it's all part of the Python 3 compat that went into 3.10. That's this commit: https://github.com/rhinstaller/pyparted/commit/c19e7195489309302ed884d903447d280c28042f it turns all instances of PyString_FromString into PyUnicode_FromString , so all those things which previously produced a 'str' in Python2 now output a 'unicode'. (It also replaces uses of PyString_AsString with PyUnicode_AsUTF8String , but I don't think that matters to this problem). I'm not sure if we can address this any easier on the pyparted side than the anaconda side, but that at least is what to look for. There are 32 occurrences of PyUnicode_FromString in current pyparted master.
The direct Python 3 equivalent of PyString_AsString is PyBytes_AsString , which in Python 3 would result in a bytes object rather than a str object. I'm not sure if just changing it that way (so the code uses PyBytes_AsString in py3 and PyString_AsString in py2) would break stuff in Python 3-land.
David notes that blivet itself now outputs unicodes in some cases, so we can't just drop the LC_ALL thing and fix pyparted somehow, we'd also have to change blivet. If I drop the LC_ALL stuff from Beta TC8 and run an install in Russian, it crashes on entering the Reclaim Space screen, when we try to concatenate an anaconda-translated string (which is a str) with the output of a blivet Size object's humanReadable() method (which, when xlate=True and we're in Russian, is a unicode).
Doing changes in pyparted would break its Python 3 support so we should really avoid that. This, unfortunately, is a result of everything going towards Python 3 installation in F22 which was dropped from the F22's targets.
Discussed at today's blocker review meeting [1]. This bug was accepted as Final Blocker - this violates "The installer must correctly display all sufficiently complete translations available for use." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-20/
anaconda-22.20.10-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/anaconda-22.20.10-1.fc22
Package libblockdev-0.11-1.fc22, python-blivet-1.0.8-1.fc22, anaconda-22.20.10-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libblockdev-0.11-1.fc22 python-blivet-1.0.8-1.fc22 anaconda-22.20.10-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6866/libblockdev-0.11-1.fc22,python-blivet-1.0.8-1.fc22,anaconda-22.20.10-1.fc22 then log in and leave karma (feedback).
libblockdev-0.11-1.fc22, python-blivet-1.0.8-1.fc22, anaconda-22.20.10-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
This does seem to be resolved in Final TC1, but as I kinda expected, we get more UnicodeDecodeError crashes: at least https://bugzilla.redhat.com/show_bug.cgi?id=1217610 .