Please leave translations in Repositories

[agaida]

They don't hurt. Not having translations in repositories and/or tarballs hurts a lot. Getting translations on the fly make it impossible for distributions like debian to have reproducible builds. Next problem is that build chroots no should have network access. The code for the build has to come from the repository, not from a not project related git server.

I'm fine with cmake get the current translations for development purposes, translators and so on - but if we make a release i will build and provide exactly the source from the release. And that should include translations.

[gilir]

On a side note, I'm worry that the needed network access will break daily builds on Ubuntu / Lubuntu (I will confirm or not this in a few days). An option may be to pack a fake deb package including all the translation, on the daily builds architecture, and make it depends on all lxqt packages.

[agaida]

@gilir - at least you have to add git to the build dependencies - but this isn't really clean. Great for development, bad for distribution

[PCMan]

@agaida Yes. That's my concern, too.
No matter what you use for development, the released tarballs should always contain complete source which can be built without problems as long as proper dependencies are met.
I'm OK with any solution from the side of a programmer, but please include the translation files in the release tarballs.

[gilir]

@agaida Yes I forgot to add it before my leave, but even with it, I'm not sure it will build correctly

[stefonarch]

I can confirm that translations in Ubuntu 16.04 for panel broke exactly some day ago, with daily builds.
Compiling panel locally here I need at least twice the time as before.

[agaida]

@gilir: imho the best is to reintegrate the current translations into the repositories - @PCMan sums it up nicely. The tranlations do not harm, in case they would be added back there will be no need to place dummy-.gitignores into the directories, there will be a fallback every time one has no network - reintegration would mean the best of two worlds, it make sure that nothing can break the builds, the translation process is decoupled and so on ...

[jleclanche]

First of all, there is no need to remove the translations to solve this. The distro builds can (and should) be based on hard commits in lxde/translations.

But that aside, god damn it @agaida. I brought this up three times and it was discussed over six months, and you step up to say it's a problem after the work is done. This is honestly pissing me off.

[jleclanche]

Regarding git for build dependencies, this is the sort of stuff you all should have brought up when I sent those repeated emails. We can do regular releases on the lxde/translations repository. And it likely won't be done for this release because nobody even mentioned any of it until now.

[agaida]

@jleclanche: i don't follow every single tree in the LXQt development - and i noticed the removal first as the transations was gone. But it is not my fault if the reality bites and you are pissed. Piss back on reality, not on me.

[jleclanche]

@agaida I sent three emails, two of them you were in CC. I also pinged the release-maintainers group about it (which you are a part of). If our biggest release maintainers aren't following on this stuff, what the hell are we including you guys for in these discussions?

[agaida]

pluralis majestatis??

[agaida]

i don't see any problems here - nothing to swear or curse at people - we have a shiny new translation system and i'm glad that we have it. This will ease the translation work a lot. The "problem" with the missed translations isn't really a problem, its only a minor point that can and should be fixed soon.

@jleclanche: relax and watch your words - and think twice before you yell and curse people

We have the new translation system right now - and i think we should use it. I will prepare a PR now for the panel - and if it work right we have achived two things:

• we have a prove that the new system works reliable
• we have new and shiny generated translations for the panel
• if there are any glitches we can iron them out without problems

[palinek]

First of all... excuse my lack of knowledge in this area.

But isn't it possible to decouple translations from the "base" packages?
I mean providing lxqt-XXX and lxqt-XXXX-translations. The lxqt-XXXX would be built as currently from the particular lxqt-XXXX repository (one package from one source repository) and all the lxqt-XXXX-translations would be built from translations repository (many packages from one repository).

[gilir]

@palinek it's exactly what I had in mind. I didn't look at it closely but IMO it's look completely acceptable (as long as it's working of course :-)) In the end, packagers with the same limitations that Debian and Ubuntu will just disable the feature "fetch translation from git during build time"

[luis-pereira]

The external translations is an attempt to improve the way we handle translations.

• Releasing translators from the development workflow that they need to "master" to be able to translate.
• Release developers from the merging translations workload.
• Make the git history cleaner.

Distributing translations in a separate package seems to be standard way.
The major question right now is how are we going to handle the upcoming release. All other issues can be solved after the release.

[agaida]

@luis-pereira - another nice sum up - had a discussion with @palinek about the discussion thing too - and with @gilir's comment about i'm nearly convinced that this could fly

For the upcoming release we should leave the translations as is. Meanwhile we should complete the translation repostiory and make it packaging ready.

@palinek - can you please ping me about some questions about the technical part of the translations handling?

[luis-pereira]

@agaida Yes, it will fly. When you say

leave the translations as is.

what does it means ?

1. leave lxqt-sudo and lxqt-panel the way they are.
2. put lxqt-sudo and lxqt-panel back on the repos

I made some experiences and intend to support .desktop translations in Pootle. Keep me in the loop. See #1044

[agaida]

@luis-pereira for now (until released) i would put the translations back to the repo. Meanwhile i would suggest to work on a complete solution for translations and .desktop-files. And if the new model works reliable (provide translations as a separated package) i would cut out all translations and translated desktop files without any compromises.

The problem now is that i know nearly nothing about translations. I know how to place some files in the right directories and eventually how to build this files from source - but nothing about doing so with translations.

EDIT: But i know that i would do the cut only if the new thing is ready for rollout and tested. That means for distributions that the packaging has to be done and in esp for debian that the new packge(s) has left the NEW cue and has entered experimental

[luis-pereira]

@agaida Reverting for the release is Ok for me and IMO the best thing to do.
You don't have to know about translations. We developers will provide CMake sugar or a script to compile .ts to .qm. I, for example, don't know much about packaging so some feedback from pacakgers is really valuable.

[jleclanche]

We've delayed this too long already, we shouldn't revert the translations release. I would rather delay the LXQt release itself if you guys need more time.

[palinek]

I think, it shouldn't be a big deal to create the build/cmake scripts fir packaging the translations separately...

[agaida]

@jleclance: We should simply re-add the files and be done with for now. Doing a new commit with the files in charge is a 5 minutes job. And we should remove the files if the new translation repo, cmake and all other things are done and tested. After the release, not short before a release.
Right now we have no benefit from removing the translations in one or two packages. The alternative is to deliver both packages without translations.

[agaida]

@luis-pereira a CMake file would be fine to prepare an upcoming translation package. Please keep in mind that such a package must be created and has to go through the NEW queue in debian. This might take a few days, a month or even longer. So it would be nice to have these things ready, if we switch to the new method.

[jleclanche]

@agaida the plan is to have the translations out of the repo for all packages, not just the one. I sent an email the other day saying that I believe we're ready to pull the trigger on it and do this for all our packages.

We need to do this before we get translations back from our translators. This is our release, this is when we test it. If we delay it another release, the exact same thing will happen then...

[agaida]

nope. its your plan and i don't agree

[jleclanche]

@agaida You've contributed zero on this, you were absent from all conversations, and you're certainly not doing the release management. It's really not your place to agree or disagree here, especially if all you're going to do is complain.

[agaida]

@jleclanche this is the right place, trust me. And if i see that things are going in the wrong direction i say it. And i'm not afraid to raise my voice. And this is exactly the time to say stop and think again.
Please not another translation desaster anymore in an LX* project. Got it?

[jleclanche]

@agaida You want reproducible builds, you lock the release to the translations from a specific commit in lxde/translations.

Again, this was discussed at length. This is no longer the time to raise theoreticals - you are several months late to that discussion. You've been given a solution to the problem you raised so this is a non-issue. And it is certainly not your place to ask LXQt devs to revert their own work just because you don't like the new workflow.

If you have further issues with the new workflow, bring them up. I'm not interested in empty complaints.

[PCMan]

@jleclanche I'm not against the technical part and I'm ok with the changes.
I, however, believe that we should be more friendly to our partners from other projects or Linux distrubutions no matter we agree or disagree with their proposals.
Some Gnome developers are quite notorious about their hostile attitude towards the community.
I hope this is not what we're going to be.

[jleclanche]

So here's what's really bugging me. The translations changes are something we've been talking about for almost a year. It was in discussions for months. @agaida, as well as all our other downstreams, were involved in those discussions but never stepped up. And now it's actually been pushed, we're getting "you must revert this right now" attitude.

Sorry if I come across rude. I am pissed off. Is this demanding attitude debian's idea of how they want to work with their upstreams?

[agaida]

@jleclanche you are pissed? Me too - if you've read my comments, i'm not against the changes - but it would be nice to have this thing finished and ready before cutting things out. I'm 100% for the separated package, i'm 100% against some re-integration at buildtime.
You might be surprised: Removing the translations from the packages repo was and is a great idea, that i fully support - i was and i am upset about cutting out working things without having the replacement ready. And the buildtime re-integration isn't a replacement, that wouldn't fly.
And i read @luis-pereira that he is ok with the revert for the release so i don't understand your reaction. If you don't like this solution there is a plan B - making the things work as a separated package and i'm fine with. As i wrote - it's only about timing.

[palinek]

FYI first shot for build translations in lxde/translations#4

(i'm short on time... so the panel will follow during the week,,,probably)

[paulolieuthier]

I second the words of @PCMan. Let's not allow our discussions to get this heated. We must be patient and keep a peaceful tone no matter how are opinions differ.

[agaida]

Thanks @palinek for providing code - your first shot works fine for simple translations (aka with no subdirectories). So no further objections against a complete move.

[stefonarch]

Don't know nothing about packaging, but I'm just wondering how in future the structure of the translation package on distro's will be:
kde-like with per-language-package?
One big package providing all stuff?
What's about modular install let's say just pacmanfm-qt or lxqt-panel, one has to install the whole lxqt-language-package?
Or am I just misled and packagers will pack the translations in the single elements?

[jleclanche]

If we do this right, the final end-user packaging layout should be unchanged from what it currently is, with translations pulled at compile time. Not entirely sure it's possible this release.

[palinek]

@stefonarch, @jleclanche The build process should be ready, that means:

• reintegration in build time (for devs, ad-hoc cloners...)
• all tranlations built by build system of translations' repo (the packager can decite if he/she wants one big lxqt-translations package or split them by component)

(see the freshly added README.md in lxde/translations#4)

[palinek]

Now... as translations from all components are moved into lxde/translations repo (and purged from components) we should consider enabling the PULL_TRANSLATIONS parameter/option by default.

@agaida, @luis-pereira, @pmattern, @paulolieuthier, @jleclanche what do you think?

[agaida]

@palinek - no objections, do it

[jleclanche]

go for it.

[luis-pereira]

do it.

[pmattern]

Technically both approaches are working without issues so I think we should set as default what's best for downstream / end users in general. Not sure which it is, though.
First, I thought it would for sure be having each component pull its translation. But some preliminary Tests involving the AUR packages on Arch seem to indicate the performance is much better when the translation repository is used to provide all translations.

[palinek]

But some preliminary Tests involving the AUR packages on Arch seem to indicate the performance is much better when the translation repository is used to provide all translations.

Sure... one full clone is faster than X sparse clones. If the build speed is essential, then you can change the AUR build scripts/packaging to use "no translations component packages" + "full translations package"

[agaida]

Imho it's a nice feature for developers and translators - and to be true - the typical end user don't compile Desktop Environments himself - and if he do (gentoo) he would use preprared ebuilds without changing them. The typical elitist Arch AUR user will use yaourt, powerbill or another script and will not change the PKGBUILDs. For debian and ubuntu users (and users of any derivative) the chance goes to nearly zero that one change the packaging. So we should decide whats best for the targeted audience and be done with. And for the distributions the maintainers will descide which way they prefere, adding -DPULL_TRANSLATIONS={ON|OFF} to a packaging receipe isn't exactly rocket science.

[paulolieuthier]

@palinek great job.

[palinek]

PULL_TRANSLATIONS option was enabled by default in liblxqt.

We can close this now, right?

[agaida]

we should