Mailinglist Archive: opensuse-packaging (186 mails)

< Previous Next >
Re: [opensuse-packaging] translation-update-upstream: new package and feature
  • From: Vincent Untz <vuntz@xxxxxxxxxxxx>
  • Date: Wed, 18 Feb 2009 12:35:14 +0100
  • Message-id: <20090218113514.GB5131@xxxxxxxxx>
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
- 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

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

(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

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

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.


Les gens heureux ne sont pas pressés.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >