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. It's now in Factory and first 94 packages are waiting for submit review. FAQ === Q: How it works? A: It features an updater: a simple tool to update the translation during initial phase of compilation, and the translation collection tool, which collects new or changed strings from one or more upstream resources (versions, branches) using the configuration file (it's called manually outside Build Service and the result is submitted). 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. Then you need to configure translation-update-upstream to point to the correct upstream resources. For more see the translation-update-upstream package HOWTO and the source package. Q: Why is this needed? Don't we get translations in upstream tarballs already? A: Our packages freeze few months before openSUSE release and then they are maintained for years in SLE. Providing a way to backport translations into frozen versions is very welcome. Q: Why a new package? Isn't translation-update sufficient? A: It is sufficient for translations provided in-house. In case of upstream translations, our translators have no control over the translation. We need a way to override upstream mistakes or errors. But translation-update package overrides everything already done forcing back the upstream version. 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. Q: Shouldn't it be better to push translations and fixes upstream? A: In general, yes. But most upstream maintainers care just about the latest stable branch. Who will care about GNOME 2.12 translation in upstream five years from now on? Q: Why not use bundle-lang package? A: You don't know source of each particular string in the bundle-lang. It may come from upstream, from a fix, from a patch. Only upstream one may be replaced by the update tool. In fact, translation-update-upstream works well with bundle-lang package. translations from the build process may get into the bundle-lang package, if the current processes defines so. Q: Does it replace po tarballs in spec files? A: Only those that come from upstream. But it may be technically possible to define Novell LCN as an additional data source. Q: Does it provide 100% translation? A: No, it does not. Only strings that were present and translated in any of newer upstream versions can be provided. Making them 100% complete still may require translators' action. 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. Q: What translation files do we have? A: We have: - translations from upstream (in tarball) - translations of strings in patches (e. g. in gnome-patch-translation) - fixes for upstream translations (provided by our testers or Novell LCN team and added in patches or additional tarballs) Now we will have also: - backported upstream translations 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) Q: Why not just pick upstream translations and put them in tarball? A: It needs to be handled manually per package. translation-update-upstream is a more sophisticated tool: It searches in all equal or later branches in the upstream SVN and merges everything usable in the old version automatically, once it is set up. Q: Do I need to call autoreconf? A: No, you don't. translation-update-upstream patches configure as well. Q: Does it run during each build? A: Only fast string merge runs during each build. It It uses pre-built tarball in translation-update-upstream and leaves following traces in the build log: Updating or.po using translation-update-upstream. Upstream string collect and compare needs several hours. It is started manually outside Build Service time after time. Q: It would perhaps add something extra to OBS, preferable onyl for SLE, but if I build the package locally with rpmbuild it wouldn't affect anything. A: No. Both use the same rpmbuild. Anything in macros affects all packages. It's cleaner to behave consistently, even at cost of one additional line. Q: It fails. What to do now? A: You can see following failures: can't open ./../foo: No such file or directory at /usr/bin/intltool-extract line 212. xgettext: error while opening "../foo" for reading: No such file or directory Most of them are upstream bugs: They forgot to package some files from their repositories resp. they based their translation on an auto-generated file. It can be considered as a bug, which can be fixed by adding a proper file to the tarball, dropping from POTFILES.in resp. using a proper source file. Upstream should be able to find such bugs by "make distcheck". Q: What is the relation to gnome-patch-translation. A: gnome-patch-translation provides patches from SuSE specific stuff in patches. translation-update-upstream provides translation for upstream things. You can use both tools in a single package. Just call translation-update-upstream first, then gnome-patch-translation-prepare. Transition info: If the submit conflicts with your work, feel free to disapprove it and do it on your own or let me know. The project.diff is really simple. References (restricted access): Feature #301344: Wants a better way to update translations bnc#377971: describes that translation-update packages are always overwriting original translations. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org