On Fri, 2006-09-01 at 07:32 -0700, Toshio Kuratomi wrote: > What makes it lengthy? Looking at the two files, the only difference is > that all the translatable fields are changed from <_TAG> to <TAG>. > Can't we make extracting the translatable strings and creating the > comps-feX.xml.in file two separate steps? In core land, the .in file is ran through a bunch of translation .po files to generate translated group texts. If more groups get added to extras, we're going to need to translate them. > Also, the live comps file is currently not synced with commits to > the .in file. So it needs to be regenerated at some point anyway... Yes, we do that in Core land too, we generate it when we make changes to the .in file. > Also, what involves the comps file in the sign/push process anyway? Is > it repoview? Isn't the plan to move repoview out to its own async > process? I do believe the comps file needs to be referenced when repodata is created so that group actions work, and they show up correctly in Pirut and such. When we do a rawhide push, the comps file is pulled out of CVS (the translated one) and that is used with createrepo. In extras land, if you don't keep the translated comps file in CVS or somewhere else, it will have to be generated on the fly from the .in file and used during the createrepo phase. > Alternately, the script that generates comps-feX.xml could place the > file in another directory (perhaps the same one as the translated comps) > so that people editing the files aren't confused as to which file they > need to edit. This is a possible solution, yes. -- Jesse Keating Release Engineer: Fedora
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
