Bug 50341 - univention-l10n-build should run locally and update UMC po files
univention-l10n-build should run locally and update UMC po files
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: General
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-2-errata
Assigned To: Dirk Wiesenthal
Florian Best
:
Depends on:
Blocks: 50521
  Show dependency treegraph
 
Reported: 2019-10-10 16:02 CEST by Dirk Wiesenthal
Modified: 2020-05-11 13:14 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Wiesenthal univentionstaff 2019-10-10 16:02:47 CEST
It would be nice to be able to
  ../../packaging/univention-ucs-translation-template/univention-l10n-build de

from anywhere in the reporitory and always get updated po files for you to inspect and adjust.

So the script should work on any developer computer, not just a UCS.

The script also needs to take UMC modules into account. Currently, it does not work for debian/*.umc-modules files.


For this to finally work, it is necessary that said source package provides debian/$pkg.univention-l10n. But this is not scope of this bug.
Comment 1 Dirk Wiesenthal univentionstaff 2019-10-10 16:14:58 CEST
(In reply to Dirk Wiesenthal from comment #0)
> For this to finally work, it is necessary that said source package provides
> debian/$pkg.univention-l10n. But this is not scope of this bug.

See Bug#50340 for example.


As for the Bug:
Done in 2495097e9d..d41530de23

Note that univention-l10n-build now translates UMC modules, but univention-l10n-install does not install them (I think). So this is for you developer to run on your machine, not to replace dh-umc-module-build in debian/rules.

I had to copy db_umc.py into the package. Let's see if I can delete it in its original source.

dh-umc-module-build should probably now just call univention-l10n-build at some point?
Comment 2 Dirk Wiesenthal univentionstaff 2019-10-10 16:37:55 CEST
(In reply to Dirk Wiesenthal from comment #1)
> I had to copy db_umc.py into the package. Let's see if I can delete it in
> its original source.

Seems like this is not possible. Used a lot in management/univention-management-console (dev/).

I _could_ replace all
import univention.dh_umc as dh_umc
with
import univention.translationhelper.umc as dh_umc

 
> dh-umc-module-build should probably now just call univention-l10n-build at
> some point?

After looking at it, it seems that now dh-umc-module-build can indeed be replaced by univention-l10n-build as it only creates the new po files for the module?

I built the package although it seems we do not need to release it as errata? So no yaml was generated.

univention-ucs-translation-template 6.0.0-5A~4.4.0.201910101627
Comment 3 Florian Best univentionstaff 2019-10-11 10:04:35 CEST
Please make sure to rebuild the packages:
* univention-management-console
* univention-self-service
* (univention-web?)
* (univention-office356?)
* (univention-directory-manager-modules?)

They were build with a broken build dependency version of univention-ucs-translation-template.
Comment 5 Florian Best univentionstaff 2019-10-11 10:30:57 CEST
Next time, please do not copy files but use "git move"! The whole history of the file is lost and the merge of the latest changes is also done in one commit without accurate bug numbers.
Comment 6 Philipp Hahn univentionstaff 2019-10-11 11:17:38 CEST
(In reply to Florian Best from comment #5)
> Next time, please do not copy files but use "git move"! The whole history of
> the file is lost and the merge of the latest changes is also done in one
> commit without accurate bug numbers.

The files was not moved, but copied - as the l10n code needs those two modules from other UCS packages, which prevents the tool from being used on non-UCS-systems AKA my notebook.
Comment 7 Florian Best univentionstaff 2019-10-11 12:40:41 CEST
I added a fix which makes it possible to build UMC again:

univention-ucs-translation-template (6.0.0-11)
5bf42f8c9576 | Bug #50341: Fix building of UMC-core
Comment 8 Florian Best univentionstaff 2019-10-16 12:37:58 CEST
OK:  ../../packaging/univention-ucs-translation-template/univention-l10n-build de works
OK: rebuild of univention-appcenter, univention-s4-connector, univention-managment-console, univention-self-service, univention-directory-manager-modules
OK: YAML
OK: '--add-comments=i18n'
btw: helper.call() should use pipes.quote()
btw: we should rename this source package into univention-l10n or something human readable, as well as the python packagge name
btw: we should unify the xgettext from umc.py and message_catalog.py
btw: we should call only univention-l10n-build in every package and remove it from umc-module-build otherwise it's called twice for packages having both (e.g. the appcenter)
Comment 10 Philipp Hahn univentionstaff 2019-10-21 08:50:32 CEST
(In reply to Florian Best from comment #8)
> btw: helper.call() should use pipes.quote()

NO! Use ['cmd', 'arg', ...]
Comment 11 Florian Best univentionstaff 2019-10-21 09:10:27 CEST
(In reply to Philipp Hahn from comment #10)
> (In reply to Florian Best from comment #8)
> > btw: helper.call() should use pipes.quote()
> 
> NO! Use ['cmd', 'arg', ...]

Use pipes.quote() for logging, not for subprocess/etc.!