I've been working towards this for a while, and I think it's ready to go - I'd like to remove the langsupport groups from F18+.
This is because: - we're not intending to expose them directly in anaconda - we now have yum-langpacks for translations
For fonts, we have the @fonts group, and for input methods, we have the @input-methods group. An install of either of those groups brings the proper default fonts & input methods for every language we ship, AFAICT.
What issues are there that might prevent removal?
Bill
----- 元のメッセージ ----- | I've been working towards this for a while, and I think it's | ready to go - I'd like to remove the langsupport groups from | F18+. | | This is because: | - we're not intending to expose them directly in anaconda | - we now have yum-langpacks for translations | | For fonts, we have the @fonts group, and for input methods, | we have the @input-methods group. An install of either of | those groups brings the proper default fonts & input methods | for every language we ship, AFAICT. | | What issues are there that might prevent removal?
After looking at current comps, the language-specific applications might be an issue after removal, such as iok. also relevant bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=847500
Since I presumed this may be happened in the future, I had some concerns on it but I couldn't find it out there now. I'm missing something else but so far only it is.
-- Akira TAGOH
One more thing is, current @fonts group has minimal sets of the packages only according to https://fedoraproject.org/wiki/PackageMaintainers/CompsXml#Fonts basically. so the language group may has some fonts packages to replace the _distribution-wide default fonts_ with the preferable typefaces. if we also change the policy of "one font per scripts" to the "one font per languages" or so, it may affects to the disk size after the installation or iso size for Live and/or some spins perhaps.
----- 元のメッセージ ----- | ----- 元のメッセージ ----- | | I've been working towards this for a while, and I think it's | | ready to go - I'd like to remove the langsupport groups from | | F18+. | | | | This is because: | | - we're not intending to expose them directly in anaconda | | - we now have yum-langpacks for translations | | | | For fonts, we have the @fonts group, and for input methods, | | we have the @input-methods group. An install of either of | | those groups brings the proper default fonts & input methods | | for every language we ship, AFAICT. | | | | What issues are there that might prevent removal? | | After looking at current comps, the language-specific applications | might be an issue after removal, such as iok. also relevant bug for | reference: https://bugzilla.redhat.com/show_bug.cgi?id=847500 | | Since I presumed this may be happened in the future, I had some | concerns on it but I couldn't find it out there now. I'm missing | something else but so far only it is. | | -- | Akira TAGOH | -- | i18n mailing list | i18n@lists.fedoraproject.org | https://admin.fedoraproject.org/mailman/listinfo/i18n
Akira TAGOH (tagoh@redhat.com) said:
One more thing is, current @fonts group has minimal sets of the packages only according to https://fedoraproject.org/wiki/PackageMaintainers/CompsXml#Fonts basically. so the language group may has some fonts packages to replace the _distribution-wide default fonts_ with the preferable typefaces.
In what cases does it do this? My reading of the fonts groups were that it only ever installed additional fonts that were options to the defaults, not new defaults. (Especially since most any desktop user who installed a langsupport group had @fonts installed anyway.)
if we also change the policy of "one font per scripts" to the "one font per languages" or so, it may affects to the disk size after the installation or iso size for Live and/or some spins perhaps.
I'm willing to test to see how much space increase this causes - I think we're OK with both KDE and GNOME, unsure about XFCE/LXDE.
| After looking at current comps, the language-specific applications | might be an issue after removal, such as iok. also relevant bug for | reference: https://bugzilla.redhat.com/show_bug.cgi?id=847500
iok is required by ibus-m17n; is that expected to change?
Bill
----- 元のメッセージ ----- | Akira TAGOH (tagoh@redhat.com) said: | > One more thing is, current @fonts group has minimal sets of the | > packages only | > according to | > https://fedoraproject.org/wiki/PackageMaintainers/CompsXml#Fonts | > basically. so the language group may has some fonts packages to | > replace the | > _distribution-wide default fonts_ with the preferable typefaces. | | In what cases does it do this? My reading of the fonts groups were | that it | only ever installed additional fonts that were options to the | defaults, not | new defaults. (Especially since most any desktop user who installed a | langsupport group had @fonts installed anyway.)
On some Indic languages say. for example, we have lohit-marathi-fonts, lohit-nepali-fonts and so on though, we don't install it by default because Marathi and Nepali uses the Devanagari-based script and basic functionality can be provided by lohit-devanagari-fonts IIRC.
That looks like Chinese vs Japanese to me - IMHO we should install it by default as we do it for Chinese and Japanese, but anyway.
| > if we also change the policy of "one font per scripts" to the "one | > font per | > languages" or so, it may affects to the disk size after the | > installation or iso | > size for Live and/or some spins perhaps. | | I'm willing to test to see how much space increase this causes - I | think | we're OK with both KDE and GNOME, unsure about XFCE/LXDE.
Great. Thanks!
| > | After looking at current comps, the language-specific | > | applications | > | might be an issue after removal, such as iok. also relevant bug | > | for | > | reference: https://bugzilla.redhat.com/show_bug.cgi?id=847500 | | iok is required by ibus-m17n; is that expected to change?
Well, the point is that it breaks one-default-application policy. both iok and eekboard is a virtual keyboard application though, we already have one on GNOME say. unfortunately it doesn't support i18n well. so we still need iok and/or eekboard. We should get involved to improve i18n support but it's another story for long term because the upstream seems getting stuck on development so far.
-- Akira TAGOH
----- Original Message -----
I've been working towards this for a while, and I think it's ready to go - I'd like to remove the langsupport groups from F18+.
This is because:
- we're not intending to expose them directly in anaconda
- we now have yum-langpacks for translations
For fonts, we have the @fonts group, and for input methods, we have the @input-methods group. An install of either of those groups brings the proper default fonts & input methods for every language we ship, AFAICT.
What issues are there that might prevent removal?
Community reaction? :-)
While I want input methods for the language I know, I don't really want the input methods I don't know to be installed.
On 25 August 2012 02:54, Bill Nottingham notting@redhat.com wrote:
What issues are there that might prevent removal?
system-config-language uses $yum groupinstall lang-support. I can see this works fine with latest F18.
Only concern is if we are not providing backward compatibility, we might need to report bugs against applications using lang-group for installing language support.
Regards, Pravin Satpute
----- 元のメッセージ ----- | system-config-language uses $yum groupinstall lang-support. I can see | this works fine with latest F18. | | Only concern is if we are not providing backward compatibility, we | might need to report bugs against applications using lang-group for | installing language support.
I'm assuming yum langinstall should still work.
-- Akira TAGOH
pravin.d.s@gmail.com (pravin.d.s@gmail.com) said:
On 25 August 2012 02:54, Bill Nottingham notting@redhat.com wrote:
What issues are there that might prevent removal?
system-config-language uses $yum groupinstall lang-support. I can see this works fine with latest F18.
Only if the group is populated, which in many cases it isn't.
I'll get a patch ready for s-c-language to use "yum langinstall" ; a similar functionality was requested for PackageKit when used by the control-center.
Bill
On 29 August 2012 04:53, Bill Nottingham notting@redhat.com wrote:
pravin.d.s@gmail.com (pravin.d.s@gmail.com) said:
On 25 August 2012 02:54, Bill Nottingham notting@redhat.com wrote:
What issues are there that might prevent removal?
system-config-language uses $yum groupinstall lang-support. I can see
this
works fine with latest F18.
Only if the group is populated, which in many cases it isn't.
I'll get a patch ready for s-c-language to use "yum langinstall" ; a similar functionality was requested for PackageKit when used by the control-center.
That's great,
Thanks, Pravin Satpute
pravin.d.s@gmail.com (pravin.d.s@gmail.com) said:
I'll get a patch ready for s-c-language to use "yum langinstall" ; a similar functionality was requested for PackageKit when used by the control-center.
That's great,
Wow, s-c-language does it all by hand - reading the comps file, importing yum, and setting up its own transaction. This would be a less trivial patch, but I'll see what can be done.
Bill
On 5 September 2012 02:16, Bill Nottingham notting@redhat.com wrote:
pravin.d.s@gmail.com (pravin.d.s@gmail.com) said:
I'll get a patch ready for s-c-language to use "yum langinstall" ; a similar functionality was requested for PackageKit when used by the
control-center.
That's great,
Wow, s-c-language does it all by hand - reading the comps file, importing yum, and setting up its own transaction. This would be a less trivial patch, but I'll see what can be done.
Indeed, that is why still able to survive without Migration to PackageKit and PolicyKit. But might be this is time to do that?
Regards, Pravin Satpute
i18n@lists.stg.fedoraproject.org
-
Akira TAGOH -
Bill Nottingham -
Ding Yi Chen -
pravin.d.s＠gmail.com