[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: builds with translations
From:       Harald Sitter <sitter () kde ! org>
Date:       2018-03-20 16:30:07
Message-ID: CAEc+18F8kejAOzn0U4XV8z6jQ2OvRDWxKmys52ygz_wmk9tmww () mail ! gmail ! com
[Download RAW message or body]

On Tue, Mar 20, 2018 at 4:46 PM, Luigi Toscano <luigi.toscano@tiscali.it> wrote:
> Boudewijn Rempt ha scritto:
> > On dinsdag 20 maart 2018 16:15:31 CET Luigi Toscano wrote:
> > > Boudewijn Rempt ha scritto:
> > > > Hi,
> > > > 
> > > > Right now, only when I create tarballs for a release are the translations
> > > > fetched. That means that only release tarballs have translations. Nightly
> > > > builds don't have translations, and whatever developers build themselves
> > > > also don't have translations. That means we've got two different ways of
> > > > building, in this case, Krita, and I don't like that situations.
> > > 
> > > You can build dynamically fetching the translations.
> > > 
> > > https://api.kde.org/ecm/kde-module/KDECMakeSettings.html#translations
> > > 
> > 
> > Hm... That documentation is a bit sparse...
> > 
> > I don't think it's a terribly good idea to make the build process download
> > things dynamically. If it's conditional on the system having internet, then
> > we'd still have two different ways a build can happen, and if it means a build
> > needs internet unconditionally, that's not good either.
> 
> Uhm, I think that's what Neon does with the daily packages.

Neon actually injects translations into the source tarballs it
generates from git. It's ultimately using the same code, but it
happens at source build time rather than binary build time (which is
what the ECM tech does).

Regarding Boud's problem, I think there are two ways to deal with
this. One is to have a cron commit translations into the git repo
(which I am not sure scripty will like? also documentation
translations might turn out to be a major git bloat). The other is the
programmatic approach from ECM.

Latter would be:

- Developers: solved by the ECM option KDE_L10N_AUTO_TRANSLATIONS. can
only happen automatically at build time AFAIK
- Nightly: could use the CLI underlying the ECM feature to fetch the
po directory into the source [1]. if you want representative nightlies
though I would suggest to spin a tarball via whatever tool you use for
releases and use that as a starting point for the nightly
- Tarball: assuming you use releaseme it's using the exact same code
as all of the above

Generally speaking, one could craft all manner of contraptions to get
the translation into the source using releaseme's library. e.g. [2] is
the code neon uses to inject l10n when generating tarballs from a VCS
build.

[1] https://phabricator.kde.org/source/releaseme/browse/master/fetchpo.rb
[2] https://github.com/blue-systems/pangea-tooling/blob/84e63fdaf25b748406699a6b8f56675230967a2a/ci-tooling/lib/ci/vcs_source_builder.rb#L74



[prev in list] [next in list] [prev in thread] [next in thread]