Ticket #81 (closed enhancement: fixed)

Opened 7 years ago

Last modified 2 years ago

Add i18n release criteria

Reported by: jlaska Owned by: adamwill
Priority: major Milestone: Fedora 14
Component: Test cases Version:
Keywords: retrospective Cc: test@…
Blocked By: Blocking:



See RHBZ#571900 - Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha


  • Currently we don't have i18n installation cases, so local language install is not tested as a demand. Untranslated pages are still existing after RC test. Such cases needed be added in test as well as release criteria.
  • Does the Fedora i18n team have any release criteria to propose?
  • RHBZ #571900 pointed out the need for a better understanding of how the language and keymap installer selections impact the installed system.

enhancement recommendation

Recommend reviewing the release criteria to ensure expectations are captured around propagating language and keymap settings from install to desktop login (/etc/sysconfig/i18n, image:Package-x-generic-16.pnggdm etc...). It may also be advised to coordinate with the installer team so that bugs can be filed for any missing functionality.

Change History

comment:1 Changed 7 years ago by adamwill

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.

comment:2 Changed 5 years ago by adamwill

  • Status changed from new to closed
  • Resolution set to fixed

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'.

comment:3 Changed 4 years ago by adamwill

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:4 Changed 4 years ago by johannbg

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

comment:5 Changed 4 years ago by tflink

  • Cc test@… added
  • Component changed from Wiki to Release criteria

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

comment:6 Changed 2 years ago by adamwill

  • Owner set to adamwill
  • Status changed from reopened to new

We did make the keyboard layout criterion explicit for f21:


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.

comment:7 Changed 2 years ago by adamwill

  • Component changed from Release criteria to Test cases

comment:8 Changed 2 years ago by adamwill

  • Status changed from new to closed
  • Resolution set to fixed

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:


so I think we can finally close this one out!

Note: See TracTickets for help on using tickets.