Description of problem: I followed this test case: https://fedoraproject.org/wiki/QA:Langpack_Yum_Application I logged in with cs_CZ locale, installed eclipse. The eclipse-nls-cs was correctly added to the install list. After that I logged out and logged in with pl_PL locale. I don't seem to be able to have eclipse-nls-pl installed automatically. I tried "yum update eclipse", "yum install eclipse", "yum update" - still it doesn't offer me to install Polish langpack automatically. But the test case says "Current locale package for the installed application should be installed automatically." Version-Release number of selected component (if applicable): Fedora 12 yum-presto-0.6.2-1.fc12.noarch yum-utils-1.1.25-1.fc12.noarch yum-metadata-parser-1.1.2-14.fc12.x86_64 yum-3.2.25-1.fc12.noarch yum-langpacks-0.1.4-2.fc13.noarch How reproducible: always Steps to Reproduce: 1. see description 2. 3.
The same problem for PackageKit integration, I don't know how to have pl translation automatically installed. I tried installing other packages, I tried to display the list of available updates - no eclipse-nls-pl there.
yum-langpacks only kicks in when there is a package update available I think.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think this is basically a limitation of yum. At least the plugin currently will only see langpacks for a new language when there is base package update. But if you have a example or counterexample for a different plugin say I can try to look more into how this might be done. I think there might also be a lot of yum overhead if we have to check for langpacks for any installed package in every yum transaction. So may be the current way is a reasonable compromise if not perfect.
I understand. So what's the proposed solution - you close this bug as WONTFIX and I'll update the test case instructions and put a note there about this use case (saying it's not supported)?
(In reply to comment #5) > I understand. So what's the proposed solution - you close this bug as WONTFIX > and I'll update the test case instructions and put a note there about this use > case (saying it's not supported)? Yes, thank you - sounds good to me. If later we find a better way to handle this case perhaps we can reopen and revisit.