In the screen of software selection, there is a category named "Languages", there is a "Chinese Support". Could we split this into "Simplified Chinese Support" and "Traditional Chinese Support" in Language Categories, as they are two different languages? Here are the benefits after this split: 1. Only install fonts for one language. For example, wqy-zenhei-fonts for Simplified Chinese, and cjkuni-fonts for Traditional Chinese, no need to install both. 2. Only install input methods for one language. For example, pinyin input method for Simplified Chinese, and chewing input method for Traditional Chinese, also no need to install both. 3. Only install one kind of language pack. For example, *-zh_CN for Simplified Chinese, and *-zh_TW for Traditional Chinese, less packages as above. Example package name: openoffice.org-langpack-zh_CN, koffice-langpack-zh_CN.
Comps controls what package groups we list.
Surely, they are different scripts, not different languages? (Although, in practice this probably doesn't make any difference.)
yes, they have different writing glyphs, Unicode code points and input methods.
Ok, I talked to Peng Wu about this, and don't think the intent was quite communicated fully. We would like to ask if anaconda could support lists of locales for language groups. Then we could have Simplified Chinese for "zh_CN,zh_SG" and Traditional Chinese for "zh_TW,zh_HK", etc. Would that be acceptable. We might be able to contribute a patch to do that if it helps. Otherwise we will just have to duplicate Chinese groups which will increase the comps maintenance burden.
Any comments on this proprosal?
Or can we get yum-langpacks working with anaconda now? Then we could finally start to remove langpacks from comps!
Here are the draft patch for this package group split: http://pwu.fedorapeople.org/comps/split-package-group.patch Feel free to comment it.
Jens - what's involved in comment #6?
(In reply to comment #8) > Jens - what's involved in comment #6? Will input from the anaconda team for a start... and testing I suppose. :)
> input from the anaconda team for a start... Would it be better to propose as a Feature?
(In reply to comment #3) > yes, they have different writing glyphs, Unicode code points and input methods. Well, they share roughly 60% of characters (though there are preferences of glyphs, see http://en.wikipedia.org/wiki/Variant_Chinese_character and most phrases are same in both places. However, I do support the split as Peng Wu suggestion. People who need to have both just tick both. :-)
(In reply to comment #11) > However, I do support the split as Peng Wu suggestion. People who need to have > both just tick both. :-) Hi, thanks for commenting. :-)
Polling about this change on Fedora Chinese mailing list is finished. Some users like this comps split for Simplified Chinese and Traditional Chinese Support, and seems no strong arguments for not splitting. URL for discussion mail: http://lists.fedoraproject.org/pipermail/chinese/2010-December/004795.html Could we try this comps split on Fedora 15?
(In reply to comment #13) > Polling about this change on Fedora Chinese mailing list is finished. > Some users like this comps split for Simplified Chinese and Traditional Chinese > Support, and seems no strong arguments for not splitting. > URL for discussion mail: > http://lists.fedoraproject.org/pipermail/chinese/2010-December/004795.html > Could we try this comps split on Fedora 15? Sorry, I mistake this bug with comps split. Just cloned this bug to track comps split. (#667898) This bug is left for anaconda RFE, to let anaconda work with yum-langpacks.
What exactly do you want anaconda to do? How would we need to interact with yum-langpacks?
(In reply to comment #15) > What exactly do you want anaconda to do? How would we need to interact with > yum-langpacks? When anaconda install Fedora, uses yum with langpacks to install packages. Let yum language packs to handle langpacks rpm package installation, for example, openoffice.org-langpack-en. After switching to yum langpacks, it seems that we can removes many entries in comps.xml.in: <packagereq type="conditional" requires="autocorr-en">autocorr-zh</packagereq> <packagereq type="conditional" requires="eclipse-platform">eclipse-nls-zh</packagereq> So we can reduces the entries in comps.xml.in, by telling yum langpacks to install the corresponding rpms for the user's languages.
Sigh - this has nothing to do with yum-langpacks! Please see comment 4. The question was: if anaconda could support multiple locales for language groups. Then we could have a "Simplified Chinese Support" language group for zh_CN,zh_SG; and "Traditional Chinese Support" group for zh_HK,zh_TW; etc.
anaconda bases the default package selection on what language you selected at the beginning of installation. We then go through all the comps groups and select every one that has a langonly= attribute that matches the currently selected language. You can break up the language groups however you want in comps, and make whatever package changes you want too. However, you can really only ever have one language selected during anaconda. If you can come up with a way to use the group definition and langonly= attributes to accomplish what you want to, go for it. But I'm not going to add yet more language-specific data that only anaconda will know about to solve this problem. We are trying to get away from that.