Dev Translations
Closed, ResolvedPublic

Description

Currently none of the dev builds pull in translations. This makes testing translations hard. In particular the lack of x-test translations makes it hard to verify i18n of our software.

Dev builds should pull in translations.

This can be done via releaseme already but probably can use some streamlining.
Also x-test is being stripped by releaseme, so an override needs to be implemented on that side. https://github.com/apachelogger/releaseme/commit/4036ec964ca36ca4455108194ee0bb980baff6a9

Example code: https://packaging.neon.kde.org/neon/ubiquity-slideshow.git/tree/debian/fetch_po.rb?h=Neon/testing

sitter created this task.Feb 7 2017, 11:58 AM
sitter updated the task description. (Show Details)Feb 8 2017, 10:30 AM

I am thinking this will need some additional changes in releaseme. Namely I think releaseme should grow a gem to expose its lib, otherwise we'll have to clone all the time. ALSO, the libs should be put in module to avoid conflict with regular CI tooling.

sitter moved this task from Ready To Do to Doing on the Neon board.Mar 3 2017, 2:30 PM
sitter claimed this task.

Limited implementation now running on kmenuedit. Working nicely.

Needs to have releaseme changed to be more gem-like so we don't have name conflicts and can nicely manage it.

sitter added a comment.EditedMar 8 2017, 1:21 PM

l10n injection is now enabled for unstable and stable for frameworks+plasma repos. Best watch out for build failures. To wholly disable this in vcs_source_builder.rb remove prepend SourceBuilderL10nExtension from the builder class.

Still TBD:

  • use relaseme as gem rather than ad-hoc cloning
  • make sure subversion is in the core image rather than installing on-demand
  • refactor source builder to support l10n without prepending the magic module
  • possibly look into controlling thread level of releaseme, with its internal default threading we may hit our heads on connection caps against anonsvn
  • possibly pass more context into container so we don't have to rely on the rugged gem to determine what the code repo URL is.
  • possibly extend releaseme to support a resolution from git url, which is what we need but currently we kinda cheat by pretending the repo_name == project_name, which isn't technically assured
sitter moved this task from Doing to Review on the Neon board.Mar 15 2017, 1:11 PM
jriddell closed this task as Resolved.Oct 3 2018, 9:26 AM