[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: Björn Strömberg <bjorn.stromberg86 () gmail ! com>
Date: 2024-01-26 8:09:03
Message-ID: CAHo5mS3ru2_sDjB18z9oy42nOZ6ij6vUWgV=_khHQzdPu2HryA () mail ! gmail ! com
[Download RAW message or body]
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=C3=B6rn
On Fri, 26 Jan 2024, 08:53 Fabian Vogt, <fabian@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 <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 an=
d
> 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 translation=
s,
> 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 use=
d.
> 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 t=
o
> avoid collisions.
>
> Cheers,
> Fabian
>
> > Cheers,
> > Albert
> >
> > >
> > > IMO the translations need to contain the Qt version in their path nam=
e,
> > > 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 wou=
ld
> > > > likely cause more effort for translators.
> > > >
> > > > Jonathan
>
>
>
[Attachment #3 (text/html)]
<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">/Björn </div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 26 Jan 2024, 08:53 \
Fabian Vogt, <<a href="mailto:fabian@ritter-vogt.de">fabian@ritter-vogt.de</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br> <br>
Am Donnerstag, 25. Januar 2024, 22:18:47 CET schrieb Albert Astals Cid:<br>
> El dissabte, 20 de gener de 2024, a les 17:39:15 (CET), Fabian Vogt va <br>
> escriure:<br>
> > Hi,<br>
> > <br>
> > Am Freitag, 8. Dezember 2023, 12:56:09 CET schrieb Jonathan Riddell:<br>
> > > On Fri, 8 Dec 2023 at 10:53, Antonio Rojas <<a \
href="mailto:arojas@archlinux.org" target="_blank" \
rel="noreferrer">arojas@archlinux.org</a>> wrote:<br> > > > > > - \
phonon: Qt5/6 versions collide (translations)<br> > > > > > <br>
> > > > > For Phonon and similar cases the translations are shared, \
why not just<br> > > > > <br>
> > > > package the translations with one of them which you know to \
be<br> > > > > installed?<br>
> > <br>
> > Is this actually valid? <br>
> <br>
> I ran lrelease from Qt5 and Qt6 over the same phonon libphonon_qt.po and they \
<br> > generated exactly bit by bit the same file.<br>
> <br>
> Is that not your experience?<br>
<br>
That's also what I get from looking at the code.<br>
<br>
> > I don't expect that Qt 5 will always be able to read<br>
> > QM files produced for Qt 6. The other way around is probably not \
guaranteed<br> > > either.<br>
> <br>
> Whether there's a promise or not that this will forever be the same, \
can't <br> > say.<br>
<br>
That's the main issue. If Qt 6 gets updated and this is no longer true,<br>
several packages would have to be changed to separate Qt5/Qt6 translations,<br>
both in the upstream projects as well as downstream packaging.<br>
<br>
If we assume that Qt 6 will always be able to read Qt 5 QM files, then<br>
it needs to be documented that translations from a Qt 5 build must be used.<br>
A Qt 6 "make install" would install the Qt 6 QM files and break the Qt 5 \
lib.<br> <br>
To avoid ^ or to be on the safe side, translations need to be versioned to<br>
avoid collisions.<br>
<br>
Cheers,<br>
Fabian<br>
<br>
> Cheers,<br>
> Albert<br>
> <br>
> > <br>
> > IMO the translations need to contain the Qt version in their path name,<br>
> > either filename or somewhere in the installation path.<br>
> > <br>
> > This is also an issue for e.g. kimageannotator:<br>
> > <a href="https://invent.kde.org/graphics/gwenview/-/merge_requests/245#note_851730" \
rel="noreferrer noreferrer" \
target="_blank">https://invent.kde.org/graphics/gwenview/-/merge_requests/245#note_851730</a><br>
> > <br>
> > Cheers,<br>
> > Fabian<br>
> > <br>
> > > > > Jonathan<br>
> > > > <br>
> > > > Because none of them is guaranteed to be installed. Only the one \
that is<br> > > > > pulled as a dependency of something will<br>
> > > <br>
> > > Can you put them in a common package that both libraries depend \
on?<br> > > > <br>
> > > Having two translations for the same repo with the same strings \
would<br> > > > likely cause more effort for translators.<br>
> > > <br>
> > > Jonathan<br>
<br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic