Hey Stanislav, Le mardi 17 février 2009, à 16:40 +0100, Stanislav Brabec a écrit :
When we freeze our package versions, new upstream translations are not updated any more. Some of our products have a long life cycle. It would be nice to get translations updated from upstream with a minimal effort.
It's the purpose of translation-update-upstream: new package and tool.
That's cool stuff for translations. Still unsure on how to handle this in the .spec files, see below. [...]
Q: How you can add its support?
A: Edit your spec file: Simply add translation-update-upstream to BuildRequires and call translation-update-upstream as a first action of build after %setup.
Do we really want to manually update all spec files? It's not that hard if we only do that for GNOME packages, but if we want to have the complete distro using this, that's a different story. People will also forget to use this when adding new packages, I guess.
Q: Why to do in compile time?
A: It is possible to do the same in using the translation override directory. But it has few disadvantages: - It would introduce strict packaging policy: - No translation fixes in spec files would be possible. - All translation fixes would be done via translation override package. - Increases installations size. We do this only for translations provided in-house.
I didn't realize that earlier, but for SLE, once it's released, we don't rebuild packages, do we? (or well, I guess they're rebuilt with SP1, SP2, etc.) I would think we'd want to just provide updated lang packages?
Q: Why we need to pollute openSUSE, if this feature is interesting only for SLE?
A: Such large change cannot be done in late beta or rc phase. It must be ready as soon as possible, only translation data file updates will have to be done in the rc phase.
Hrm, this sounds wrong :-) If it's not interesting for openSUSE, then, well, it just shouldn't go in openSUSE. So the question is "how can we make it interesting for openSUSE?". Since the packages won't be rebuilt once a version of openSUSE is released, I was thinking that all the logic you implemented could be used for updating the bundle lang packages. (yes, I'm repeating what I said earlier ;-))
Q: Isn't it best to modify OBS to support this?
A: No: - The tool has to have access to network. - String collecting may require manual intervence in case of upstream errors.
Q: Wouldn't it be better to modify %setup?
A: No: - It would bring additional "magical" divergence from upstream. - Things may need tuning (e. g. for non-standard po directories)
As much as I hate divergence from upstream... I also hate manual work. It sounds to me like we could have %setup look at some file to know if a package should be using this feature, and if it should how it should use it. Okay. Stepping back a bit. Could we make something export the POT files of all packages, and then have your scripts run on those files, independently of the package build? This is non-intrusive for packages, and it would make it easy to build updated lang bundles. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org