Agree with Fabian, this is a case of accidental duplication, so translations should be versioned, otherwise its a debt that will bite us in the long run.
/Björn On Fri, 26 Jan 2024, 08:53 Fabian Vogt, <fab...@ritter-vogt.de> wrote: > 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 <aro...@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 > > >
