<div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 nov. 2022 à 18:54, Andreas Cord-Landwehr <<a href="mailto:cordlandwehr@kde.org">cordlandwehr@kde.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Josep,<br>
<br>
thank you for the feedback! So I understand, the typical use case is that are <br>
is usually only one (active) translator per PO file. So, for those files we do <br>
not have to bother with old format copyright statements and simply can switch.<br>
<br></blockquote><div><br></div><div>Not necessary. For example, when there are bugs, it's not always the usual translator that fixes it.</div><div> </div><div>For French team, I don't think we have any issue with the change. Can there be any issue with teams using the summit worflow?<br></div><div>On my side, I think it would be nice at some point to have a script that applies the change to all the po files in KDE to use the SPDX statements so we don"t have the discrepancy with unmaintained files.</div><div><br></div><div>Cheers,</div><div><br></div><div>Johnny</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regarding your concerns:<br>
1) At least for Lokalize it should be super easy to provide it via Flatpak and <br>
similar tools to enable translators on older/slower moving distros to easily <br>
use a modern version once PO files default to SPDX format.<br>
2) If we have old and new copyright format in the same file or even with <br>
statements of the same author, this should be easily to fix by an update <br>
script. I can gladly support/provide such a script to help in this conversion.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
At the moment, my main concern is to get the needed applications ready to be <br>
able to start introducing SPDX based copyright information per default. As I <br>
understand you, it is not a problem if we already now turn the switch in <br>
Lokalize to update copyright to SPDX for everybody who is using a very new <br>
version of Lokalize (so, the version in which the reference patch is first <br>
released).<br>
<br>
If anybody else as concerns and remarks, please raise them. Since Gears <br>
feature freeze is already tomorrow, I am afraid that this change in Lokalize <br>
will be a topic for the 23.04 release anyways.<br>
<br>
Cheers,<br>
Andreas<br>
<br>
On Freitag, 4. November 2022 20:01:46 CET Josep M. Ferrer wrote:<br>
> El 3/11/22 a les 13:47, Andreas Cord-Landwehr ha escrit:<br>
> > Hi, following up the discussion in the separate thread ("reuse compliance<br>
> > and imported po/"), I need some input about the practical steps to<br>
> > achieve this.<br>
> > <br>
> > At [1] I have a merge-request prepared that updates Lokalize to:<br>
> > - understand both, the "old" copyright statements and the "new" SPDX<br>
> > copyright statements<br>
> > - changes to SPDX copyright statements per default<br>
> > <br>
> > The technical change here is the simple part, but we have to look into the<br>
> > translation workflow, where I am not an expert. Essentially, we have two<br>
> > main questions on table:<br>
> > <br>
> > a) Is it acceptable to have a transition phase where we have both kinds of<br>
> > copyright statements inside PO files because translators of the same file<br>
> > use different tools/different versions of tools that do not yet all<br>
> > support SPDX based statements? (please also say if there are more tools<br>
> > additional to Lokalize, GTranslator and Poedit that we have to look at)<br>
> <br>
>  From my POV, it's no necessary the transition phase: a single PO file<br>
> must have the traditional copyright statement or the SPDX copyright<br>
> statement, but no both. But other translation teams may have a different<br>
> needs.<br>
> <br>
> I've just tested an option in Pology suite<br>
> (<a href="https://invent.kde.org/sdk/pology" rel="noreferrer" target="_blank">https://invent.kde.org/sdk/pology</a>):<br>
> <br>
> $ posieve set-header -scopyright:'SPDX-FileCopyrightText: 2021, 2022 Foo<br>
> Name <<a href="mailto:foo@kde.org" target="_blank">foo@kde.org</a>>' akonadi_knut_resource.po<br>
> <br>
> And changed the old copyright statement to SPDF copyright. So, it's OK.<br>
> <br>
> > b) Is it acceptable to only support forward migration from "old" to "new"<br>
> > copyright statements and not the way back?<br>
> <br>
> Also, from my POV, our team only need the forward migration.<br>
> <br>
> > And actually, are you OK with going towards SPDX based copyright<br>
> > statements<br>
> > our do you have any fundamental concerns? As Harald already said, it would<br>
> > be a very big help for our automatic license/copyright check tooling<br>
> > because most of the code already is ported to SPDX based statements.<br>
> <br>
> I have some concerns:<br>
> <br>
> 1) Some distros will ship a new Lokalize version in a year or two, with<br>
> the SPDF compliant copyright statement. So, this movement will be slow.<br>
> <br>
> 2) At some point, when all teams use SPDF compliant copyright<br>
> statements, there will be PO files with old copyright statements ( some<br>
> PO files untouched since a decade or more, or inactive teams). I<br>
> understand there will be a massive migration. Is this assumption correct?<br>
> <br>
> Thanks!<br>
> <br>
> Josep M. Ferrer<br>
> <br>
> > Best regards,<br>
> > Andreas<br>
> > <br>
> > [1]<a href="https://invent.kde.org/sdk/lokalize/-/merge_requests/22" rel="noreferrer" target="_blank">https://invent.kde.org/sdk/lokalize/-/merge_requests/22</a><br>
> > <br>
> > PS: Yes, I deliberately only said "copyright" and not "license" for now,<br>
> > because "license statements" will be a quite harder problem to tackle<br>
> > because it is probably not a syntactical but a semantic change...<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div>