De : "Jeremy Katz" katzj@redhat.com
Actually, nothing says that additional repos can't have their own specspo-type package as well.
This is considerably upping the bar to creation of a new repository, and making impossible the common "collect rpms, launch createrepo" workflow
Also, moving the translations into the spec files is pretty painful also. It makes the spec file _much_ more complicated to actually edit
Note I'm not advocating pushing the translations in the spec file, but somewhere within the package (could be a SourceX-like declaration referencing a detached translation file)
and work with and it also means the package has to be rebuilt to get translations of package metadata added.
Packages need to be rebuilt anyway when the localisation teams translate the app (and translators complain we don't do it)
Also how often are Description and Summary changed? Pretty never in my experience. That would mean a new Fedora package would be rebuilt a few times for translations just after hitting the repository and then never again. (and this can be hidden to users by pushing new packages to rawhide-only the time translators work on them)
All of the above said, specspo probably _isn't_ the right answer...
Yes, it was hyped as necessary to make translator work easy, and now you have translators complaining of it.
Regards,
nicolas.mailhot@laposte.net napsal(a):
De : "Jeremy Katz" katzj@redhat.com
Actually, nothing says that additional repos can't have their own specspo-type package as well.
This is considerably upping the bar to creation of a new repository, and making impossible the common "collect rpms, launch createrepo" workflow
Also, moving the translations into the spec files is pretty painful also. It makes the spec file _much_ more complicated to actually edit
Note I'm not advocating pushing the translations in the spec file, but somewhere within the package (could be a SourceX-like declaration referencing a detached translation file)
and work with and it also means the package has to be rebuilt to get translations of package metadata added.
Packages need to be rebuilt anyway when the localisation teams translate the app (and translators complain we don't do it)
Also how often are Description and Summary changed? Pretty never in my experience. That would mean a new Fedora package would be rebuilt a few times for translations just after hitting the repository and then never again. (and this can be hidden to users by pushing new packages to rawhide-only the time translators work on them)
All of the above said, specspo probably _isn't_ the right answer...
Yes, it was hyped as necessary to make translator work easy, and now you have translators complaining of it.
Regards,
I think that the main problem is that those files are really to big. 8k+ strings is really great load. It would be better if the specspo files were divided correspondingly to categories of the packages or maybe alphabetically into a few smaller files.
About the description in the package itself. Just an idea. I would not try to get the translation into package but try to look for it in the package and if it is there update corresponding string at the .po file.
Στις 12-09-2007, ημέρα Τετ, και ώρα 15:43 +0200, ο/η nicolas.mailhot@laposte.net έγραψε:
De : "Jeremy Katz" katzj@redhat.com
Actually, nothing says that additional repos can't have their own specspo-type package as well.
This is considerably upping the bar to creation of a new repository, and making impossible the common "collect rpms, launch createrepo" workflow
Is it that bad really? It's a step that could be done by a script and have the POs hosted at the repo's own VCS, reached by transifex.
All of the above said, specspo probably _isn't_ the right answer...
Yes, it was hyped as necessary to make translator work easy, and now you have translators complaining of it.
Is there a way to have these PO files cut into more "logical" pieces? Translators for example would like to work incrementally from the most to the less important ones. Or, have a PO with packages that will (most likely) show up in the main screens of pirut, etc.
Maybe specspo is a good opportunity to start thinking about installing a pootle server. If the strings don't change very often, the maintenance cost (merging, etc) could be bearable.
-d
Le Sam 22 septembre 2007 19:50, Dimitris Glezos a écrit :
Στις 12-09-2007, ημέρα Τετ, και ώρα 15:43 +0200, ο/η nicolas.mailhot@laposte.net έγραψε:
De : "Jeremy Katz" katzj@redhat.com
Actually, nothing says that additional repos can't have their own specspo-type package as well.
This is considerably upping the bar to creation of a new repository, and making impossible the common "collect rpms, launch createrepo" workflow
Is it that bad really? It's a step that could be done by a script and have the POs hosted at the repo's own VCS, reached by transifex.
Small local or third-party repositories have almost no infrastructure, they manage bunches of rpm and nothing else, so if translations are not embedded in the packages themselves (in the spec of in a detached file inside the srpm) they get lost.
You'll note that Fedora is no different, we do not require a working yum repo for new package submissions, just a srpm somewhere on the net
Regards