Note that we did do some 'workarounds' in the existing criteria for this, late in F13 cycle. We added some keyboard layout testing to an existing install validation test case - https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28encrypted%29_install - and added a desktop validation test case which does i18n - https://fedoraproject.org/wiki/QA:Testcase_desktop_login . (Though we seem to have left that out of the validation tables for late F13 builds). I agree we should capture this in the release criteria explicitly.

We finally added i18n criteria during the F16 cycle. See https://lists.fedoraproject.org/pipermail/test/2011-October/103588.html .

The criterion that was added was "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use".

Earlier, we added a preamble to the criteria which experience has shown sufficiently covers "propagating language and keymap settings from install to desktop login" - we usually are able to discuss keymap issues on the basis of the existing criteria plus the preamble language about 'specific configurations'.

On second thoughts, re-opening this; the criteria judo required to cover keymap issues is kind of heavy and probably doesn't pass the raptor test. If the whole team of 'experienced' blocker review people were eaten by raptors tomorrow, I'm not sure someone coming in and doing the blocker review process from scratch would figure out the process hack of 'keymap selection failing is a violation of the 'encrypted partition passphrase entry' criterion in the case of a non-default keymap'. It's a clever process hack, but it's hardly transparent. So it may be desirable to have more explicit criteria for keymap selection still.

Unless you are going to move the entire software translation deadline ahead of alpha ( and all related criteria and test case ) the solution is to move the "encrypted partition passphrase entry" criterion for alpha to beta where it belong.

I think it's time that the QA community stops chasing the broken development process anaconda is following by changing adjusting our release criteria everyday trying to meet it. That truly is something they need to fix in-house, including how every release cycle they manage to break the keyboard/key mapping selection

Changing component to be more appropriate (and test new cc system)

We did make the keyboard layout criterion explicit for f21:

https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Keyboard_layout_configuration

we still have one thing missing here, though - an explicit test case for testing the install in all different languages, to catch crashes (unicode crasher stuff is not uncommon) and UI problems (often we find some spoke or other goes wiggy in verbose languages like German). I'll draft one up.

So I found we actually do have test cases already, created for the i18n test days, we'd just never pulled them into the release validation pages. They're not quite what I did, which was try running the installer in every language on the list, but close enough for government work.

I cleaned those test cases up and added them to the matrix:

https://fedoraproject.org/wiki/Template:Installation_test_matrix#Internationalization_and_Localization

so I think we can finally close this one out!