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

List:       kde-release-team
Subject:    Re: Report of packaging issues with mega release - Qt5/6 translation conflicts
From:       Fabian Vogt <fabian () ritter-vogt ! de>
Date:       2024-01-26 7:53:03
Message-ID: 4891550.31r3eYUQgx () linux-e202 ! suse ! de
[Download RAW message or body]

Hi,

Am Donnerstag, 25. Januar 2024, 22:18:47 CET schrieb Albert Astals Cid:
> El dissabte, 20 de gener de 2024, a les 17:39:15 (CET), Fabian Vogt va 
> escriure:
> > Hi,
> > 
> > Am Freitag, 8. Dezember 2023, 12:56:09 CET schrieb Jonathan Riddell:
> > > On Fri, 8 Dec 2023 at 10:53, Antonio Rojas <arojas@archlinux.org> wrote:
> > > > > - phonon: Qt5/6 versions collide (translations)
> > > > > 
> > > > > For Phonon and similar cases the translations are shared, why not just
> > > > 
> > > > package the translations with one of them which you know to be
> > > > installed?
> > 
> > Is this actually valid? 
> 
> I ran lrelease from Qt5 and Qt6 over the same phonon libphonon_qt.po and they 
> generated exactly bit by bit the same file.
> 
> Is that not your experience?

That's also what I get from looking at the code.

> > I don't expect that Qt 5 will always be able to read
> > QM files produced for Qt 6. The other way around is probably not guaranteed
> > either.
> 
> Whether there's a promise or not that this will forever be the same, can't 
> say.

That's the main issue. If Qt 6 gets updated and this is no longer true,
several packages would have to be changed to separate Qt5/Qt6 translations,
both in the upstream projects as well as downstream packaging.

If we assume that Qt 6 will always be able to read Qt 5 QM files, then
it needs to be documented that translations from a Qt 5 build must be used.
A Qt 6 "make install" would install the Qt 6 QM files and break the Qt 5 lib.

To avoid ^ or to be on the safe side, translations need to be versioned to
avoid collisions.

Cheers,
Fabian

> Cheers,
>   Albert
> 
> > 
> > IMO the translations need to contain the Qt version in their path name,
> > either filename or somewhere in the installation path.
> > 
> > This is also an issue for e.g. kimageannotator:
> > https://invent.kde.org/graphics/gwenview/-/merge_requests/245#note_851730
> > 
> > Cheers,
> > Fabian
> > 
> > > > > Jonathan
> > > > 
> > > > Because none of them is guaranteed to be installed. Only the one that is
> > > > pulled as a dependency of something will
> > > 
> > > Can you put them in a common package that both libraries depend on?
> > > 
> > > Having two translations for the same repo with the same strings would
> > > likely cause more effort for translators.
> > > 
> > > Jonathan


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