Mailinglist Archive: opensuse-packaging (186 mails)

< Previous Next >
[opensuse-packaging] translation-update-upstream: new package and feature
  • From: Stanislav Brabec <sbrabec@xxxxxxx>
  • Date: Tue, 17 Feb 2009 16:40:11 +0100
  • Message-id: <1234885211.23616.119.camel@xxxxxxxxxxxxxx>
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >