Traditional Chinese would have got a US layout anyway because there's no separate keyboard layout defined for zh_TW (and note that the 'cn' layout is actually just the same as 'us' anyway, so for now the difference is purely cosmetic). "EE. UU." is Spanish for USA.
You're right that there is a problem here, though. What's happening is that keyboard-configuration/layoutcode (and presumably keyboard- configuration/variantcode if the first stage did anything that required a variant) has its value copied over from the first stage, so that the second stage thinks it already has a default answer to that question. Fixing this is tricky because there are a lot of conflicting requirements, some of which affect use cases other than OEM Services: we need to copy the keyboard-configuration questions so that future upgrades of keyboard-configuration don't ask questions which have already been answered at installation time; we need to preserve the ability of OEMs to preseed the keyboard page if they're shipping machines with a known keyboard layout; and we need to make your case work. I think a reasonable answer to this would be to simply not copy k-c questions from the first stage in OEM mode. This seems to do the trick, and would still allow for OEMs to explicitly preseed it after the first stage has finished. I've missed the beta-2 boat now, but I'll do this for final release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/741304 Title: Language packs are not being installed for selected languages during oem-config -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
