Re: Copying po/docbook files to repositories nightly
Le dim. 2 oct. 2022 à 07:51, Albert Astals Cid a écrit : > El diumenge, 2 d’octubre de 2022, a les 7:37:26 (CEST), Albert Astals Cid > va > escriure: > > El divendres, 2 de setembre de 2022, a les 23:24:21 (CEST), Albert Astals > > Cid > > va escriure: > > > As you may know, translations for apps don't live in the same place as > the > > > code for the apps themselves. > > > > > > This greatly benefits translators but is not awesome for the release > > > management side of things since it means that for each release we need > to > > > not forget to copy the appropriate files to the appropriate place, > makes > > > tagging somewhat harder, etc. > > > > > > For a while now we have been running an "experimental" > copy-po-qm-docbook- > > > back-to-repository in a number of "select" repositories and it seems to > > > have worked quite well, you can seem one example in > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > The idea is to enable this for all repositories. > > > > This has now been enabled for master branch and according to scripty logs > > all seems to have worked. > > > > Please inspect your repositories and make sure the po files are there > where > > they should and nothing broke. > > Nothing broke but at least it seems the po files did not get commited to > these > projects (maybe there are some more problematic repots, please check yours > if > it's not part of KDE Gear, KDE Framworks or Plasma, those are the ones i > did > check more thoroughly and fix if found something) > > digikam > gcompris > kaffeine > kbibtex > kphotoalbum > kst-plot > rkward > skrooge > trojita > ubiquity-slideshow-neon > > Because it is ignoring the po folder at the .gitignore file level, please > don't > do that anymore. > > Cheers, > Albert > > I've fixed it for GCompris and its website. Thanks, Johnny > > > > Also please make sure you adapt your releasing scripts if you release > from > > master. > > > > Cheers, > > Albert > > > > > This is a heads up, as a developer there's nothing you need to do, at > most > > > remove the po/ folder from .gitignore if for some reason it is there. > > > > > > If you're a packager you will need to make sure your scripts don't try > to > > > copy po/qm/docbook files anymore when doing a release once this is > > > activated. > > > > > > My plan would be to enable this scripts over Akademy so we have the > high > > > bandwidth there to fix things if needed. > > > > > > Opinions? Comments? > > > > > > Cheers, > > > > > > Albert > > > > >
Re: Copying po/docbook files to repositories nightly
El diumenge, 2 d’octubre de 2022, a les 7:37:26 (CEST), Albert Astals Cid va escriure: > El divendres, 2 de setembre de 2022, a les 23:24:21 (CEST), Albert Astals > Cid > va escriure: > > As you may know, translations for apps don't live in the same place as the > > code for the apps themselves. > > > > This greatly benefits translators but is not awesome for the release > > management side of things since it means that for each release we need to > > not forget to copy the appropriate files to the appropriate place, makes > > tagging somewhat harder, etc. > > > > For a while now we have been running an "experimental" copy-po-qm-docbook- > > back-to-repository in a number of "select" repositories and it seems to > > have worked quite well, you can seem one example in > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > The idea is to enable this for all repositories. > > This has now been enabled for master branch and according to scripty logs > all seems to have worked. > > Please inspect your repositories and make sure the po files are there where > they should and nothing broke. Nothing broke but at least it seems the po files did not get commited to these projects (maybe there are some more problematic repots, please check yours if it's not part of KDE Gear, KDE Framworks or Plasma, those are the ones i did check more thoroughly and fix if found something) digikam gcompris kaffeine kbibtex kphotoalbum kst-plot rkward skrooge trojita ubiquity-slideshow-neon Because it is ignoring the po folder at the .gitignore file level, please don't do that anymore. Cheers, Albert > > Also please make sure you adapt your releasing scripts if you release from > master. > > Cheers, > Albert > > > This is a heads up, as a developer there's nothing you need to do, at most > > remove the po/ folder from .gitignore if for some reason it is there. > > > > If you're a packager you will need to make sure your scripts don't try to > > copy po/qm/docbook files anymore when doing a release once this is > > activated. > > > > My plan would be to enable this scripts over Akademy so we have the high > > bandwidth there to fix things if needed. > > > > Opinions? Comments? > > > > Cheers, > > > > Albert
Re: Copying po/docbook files to repositories nightly
El divendres, 2 de setembre de 2022, a les 23:24:21 (CEST), Albert Astals Cid va escriure: > As you may know, translations for apps don't live in the same place as the > code for the apps themselves. > > This greatly benefits translators but is not awesome for the release > management side of things since it means that for each release we need to > not forget to copy the appropriate files to the appropriate place, makes > tagging somewhat harder, etc. > > For a while now we have been running an "experimental" copy-po-qm-docbook- > back-to-repository in a number of "select" repositories and it seems to have > worked quite well, you can seem one example in > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > The idea is to enable this for all repositories. This has now been enabled for master branch and according to scripty logs all seems to have worked. Please inspect your repositories and make sure the po files are there where they should and nothing broke. Also please make sure you adapt your releasing scripts if you release from master. Cheers, Albert > > This is a heads up, as a developer there's nothing you need to do, at most > remove the po/ folder from .gitignore if for some reason it is there. > > If you're a packager you will need to make sure your scripts don't try to > copy po/qm/docbook files anymore when doing a release once this is > activated. > > My plan would be to enable this scripts over Akademy so we have the high > bandwidth there to fix things if needed. > > Opinions? Comments? > > Cheers, > Albert
Re: Copying po/docbook files to repositories nightly
Le dim. 4 sept. 2022 à 11:14, Albert Astals Cid a écrit : > El dissabte, 3 de setembre de 2022, a les 10:44:01 (CEST), Johnny Jazeix > va > escriure: > > Hi, > > > > this is great. For GCompris, we have some stuff to handle translation > that > > differs from the usual (for example, the po files are in > > po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to > > harmonise it with the usual. > > For the stable branch, we don't plan to do a release before December so > it > > would be better to not apply it at Akademy (except if the change on > > GCompris side is easily backportable but I have to check). > > If you don't plan to do a release before December you have 3 months to > make > sure it works, i don't understand the problem. > > Albert > > Priorities and time it requires to update the actual process. It's not just changing the handling of the tree of files, it's also make sure we don't ship translations with enough content and have it in a transparent way for each platform. For now, it's a script that fetch the po files and only take in account the good ones, we make a release tgz and we use it on all platforms. With this change, all the po will already be there (even the ones we don't want to ship) so we need to ensure at build time that the languages we don't want won't be in packages. Regarding the actual stable branch, even if we don't plan to make releases, it will still mean the new po files will be added in git so we need to ensure it does not break the actual flow in this branch or ship unwanted files. So yes, the work to do is defined, the available time, less. It will probably be done on time but the aim of this thread was to give opinions (big +1 on the idea) and comments (there is work to do, it's worth it but not free). Cheers, Johnny > > > > Cheers, > > > > Johnny > > > > Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid a écrit > : > > > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl > USTA > > > va > > > > > > escriure: > > > > Just wanted to learn one thing , isn't this will populate the logs > with > > > > lots of entries on git log history ? > > > > I mean right now I am tracking git changes based on changes in > history > > > > > > but > > > > > > > this will add a new entry > > > > each night or I understand this wrong ? > > > > > > If you look a the example URL i posted you can see there's not a new > entry > > > each night. > > > > > > Cheers, > > > > > > Albert > > > > > > > Also wouldn't it be possible to fetch related translation on the fly > > > > from > > > > the software side after releases ? > > > > I mean translation of language X might be getting a little back lets > say > > > > 5.26 released but team X > > > > might be late to complete their translation on time but user should > have > > > > chance to download it > > > > after the release of it (without waiting for the next tagging ). > > > > Wouldn't > > > > it be possible to download and install the latest > > > > language data in applications just like users do with themes? > > > > > > > > Thank you > > > > > > > > Ömer Fadıl Usta > > > > PGP key : 0xfd11561976b1690b > > > > about.me/omerusta > > > > > > > > > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde > şunu > > > > > > > > yazdı: > > > > > As you may know, translations for apps don't live in the same > place as > > > > > > the > > > > > > > > code for the apps themselves. > > > > > > > > > > This greatly benefits translators but is not awesome for the > release > > > > > management > > > > > side of things since it means that for each release we need to not > > > > > > forget > > > > > > > > to > > > > > copy the appropriate files to the appropriate place, makes tagging > > > > > somewhat > > > > > harder, etc. > > > > > > > > > > For a while now we have been running an "experimental" > > > > > > copy-po-qm-docbook- > > > > > > > > back-to-repository in a number of "select" repositories and it > seems > > > > > to > > > > > have > > > > > worked quite well, you can seem one example in > > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > > > > > The idea is to enable this for all repositories. > > > > > > > > > > This is a heads up, as a developer there's nothing you need to do, > at > > > > > > most > > > > > > > > remove the po/ folder from .gitignore if for some reason it is > there. > > > > > > > > > > If you're a packager you will need to make sure your scripts don't > try > > > > > > to > > > > > > > > copy > > > > > po/qm/docbook files anymore when doing a release once this is > > > > > > activated. > > > > > > > > My plan would be to enable this scripts over Akademy so we have the > > > > > > high > > > > > > > > bandwidth there to fix things if needed. > > > > > > > > > > Opinions? Comments? > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > >
Re: Copying po/docbook files to repositories nightly
Hi, this is great. For GCompris, we have some stuff to handle translation that differs from the usual (for example, the po files are in po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to harmonise it with the usual. For the stable branch, we don't plan to do a release before December so it would be better to not apply it at Akademy (except if the change on GCompris side is easily backportable but I have to check). Cheers, Johnny Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid a écrit : > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA > va > escriure: > > Just wanted to learn one thing , isn't this will populate the logs with > > lots of entries on git log history ? > > I mean right now I am tracking git changes based on changes in history > but > > this will add a new entry > > each night or I understand this wrong ? > > If you look a the example URL i posted you can see there's not a new entry > each night. > > Cheers, > Albert > > > Also wouldn't it be possible to fetch related translation on the fly from > > the software side after releases ? > > I mean translation of language X might be getting a little back lets say > > 5.26 released but team X > > might be late to complete their translation on time but user should have > > chance to download it > > after the release of it (without waiting for the next tagging ). Wouldn't > > it be possible to download and install the latest > > language data in applications just like users do with themes? > > > > Thank you > > > > Ömer Fadıl Usta > > PGP key : 0xfd11561976b1690b > > about.me/omerusta > > > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu > > > > yazdı: > > > As you may know, translations for apps don't live in the same place as > the > > > code for the apps themselves. > > > > > > This greatly benefits translators but is not awesome for the release > > > management > > > side of things since it means that for each release we need to not > forget > > > to > > > copy the appropriate files to the appropriate place, makes tagging > > > somewhat > > > harder, etc. > > > > > > For a while now we have been running an "experimental" > copy-po-qm-docbook- > > > back-to-repository in a number of "select" repositories and it seems to > > > have > > > worked quite well, you can seem one example in > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > The idea is to enable this for all repositories. > > > > > > This is a heads up, as a developer there's nothing you need to do, at > most > > > remove the po/ folder from .gitignore if for some reason it is there. > > > > > > If you're a packager you will need to make sure your scripts don't try > to > > > copy > > > po/qm/docbook files anymore when doing a release once this is > activated. > > > > > > My plan would be to enable this scripts over Akademy so we have the > high > > > bandwidth there to fix things if needed. > > > > > > Opinions? Comments? > > > > > > Cheers, > > > > > > Albert > > > > >
Re: Copying po/docbook files to repositories nightly
El dissabte, 3 de setembre de 2022, a les 10:44:01 (CEST), Johnny Jazeix va escriure: > Hi, > > this is great. For GCompris, we have some stuff to handle translation that > differs from the usual (for example, the po files are in > po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to > harmonise it with the usual. > For the stable branch, we don't plan to do a release before December so it > would be better to not apply it at Akademy (except if the change on > GCompris side is easily backportable but I have to check). If you don't plan to do a release before December you have 3 months to make sure it works, i don't understand the problem. Albert > > Cheers, > > Johnny > > Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid a écrit : > > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA > > va > > > > escriure: > > > Just wanted to learn one thing , isn't this will populate the logs with > > > lots of entries on git log history ? > > > I mean right now I am tracking git changes based on changes in history > > > > but > > > > > this will add a new entry > > > each night or I understand this wrong ? > > > > If you look a the example URL i posted you can see there's not a new entry > > each night. > > > > Cheers, > > > > Albert > > > > > Also wouldn't it be possible to fetch related translation on the fly > > > from > > > the software side after releases ? > > > I mean translation of language X might be getting a little back lets say > > > 5.26 released but team X > > > might be late to complete their translation on time but user should have > > > chance to download it > > > after the release of it (without waiting for the next tagging ). > > > Wouldn't > > > it be possible to download and install the latest > > > language data in applications just like users do with themes? > > > > > > Thank you > > > > > > Ömer Fadıl Usta > > > PGP key : 0xfd11561976b1690b > > > about.me/omerusta > > > > > > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu > > > > > > yazdı: > > > > As you may know, translations for apps don't live in the same place as > > > > the > > > > > > code for the apps themselves. > > > > > > > > This greatly benefits translators but is not awesome for the release > > > > management > > > > side of things since it means that for each release we need to not > > > > forget > > > > > > to > > > > copy the appropriate files to the appropriate place, makes tagging > > > > somewhat > > > > harder, etc. > > > > > > > > For a while now we have been running an "experimental" > > > > copy-po-qm-docbook- > > > > > > back-to-repository in a number of "select" repositories and it seems > > > > to > > > > have > > > > worked quite well, you can seem one example in > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > > > > > The idea is to enable this for all repositories. > > > > > > > > This is a heads up, as a developer there's nothing you need to do, at > > > > most > > > > > > remove the po/ folder from .gitignore if for some reason it is there. > > > > > > > > If you're a packager you will need to make sure your scripts don't try > > > > to > > > > > > copy > > > > po/qm/docbook files anymore when doing a release once this is > > > > activated. > > > > > > My plan would be to enable this scripts over Akademy so we have the > > > > high > > > > > > bandwidth there to fix things if needed. > > > > > > > > Opinions? Comments? > > > > > > > > Cheers, > > > > > > > > Albert
Re: Copying po/docbook files to repositories nightly
El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA va escriure: > Just wanted to learn one thing , isn't this will populate the logs with > lots of entries on git log history ? > I mean right now I am tracking git changes based on changes in history but > this will add a new entry > each night or I understand this wrong ? If you look a the example URL i posted you can see there's not a new entry each night. Cheers, Albert > Also wouldn't it be possible to fetch related translation on the fly from > the software side after releases ? > I mean translation of language X might be getting a little back lets say > 5.26 released but team X > might be late to complete their translation on time but user should have > chance to download it > after the release of it (without waiting for the next tagging ). Wouldn't > it be possible to download and install the latest > language data in applications just like users do with themes? > > Thank you > > Ömer Fadıl Usta > PGP key : 0xfd11561976b1690b > about.me/omerusta > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu > > yazdı: > > As you may know, translations for apps don't live in the same place as the > > code for the apps themselves. > > > > This greatly benefits translators but is not awesome for the release > > management > > side of things since it means that for each release we need to not forget > > to > > copy the appropriate files to the appropriate place, makes tagging > > somewhat > > harder, etc. > > > > For a while now we have been running an "experimental" copy-po-qm-docbook- > > back-to-repository in a number of "select" repositories and it seems to > > have > > worked quite well, you can seem one example in > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > > > The idea is to enable this for all repositories. > > > > This is a heads up, as a developer there's nothing you need to do, at most > > remove the po/ folder from .gitignore if for some reason it is there. > > > > If you're a packager you will need to make sure your scripts don't try to > > copy > > po/qm/docbook files anymore when doing a release once this is activated. > > > > My plan would be to enable this scripts over Akademy so we have the high > > bandwidth there to fix things if needed. > > > > Opinions? Comments? > > > > Cheers, > > > > Albert
Re: Copying po/docbook files to repositories nightly
Just wanted to learn one thing , isn't this will populate the logs with lots of entries on git log history ? I mean right now I am tracking git changes based on changes in history but this will add a new entry each night or I understand this wrong ? Also wouldn't it be possible to fetch related translation on the fly from the software side after releases ? I mean translation of language X might be getting a little back lets say 5.26 released but team X might be late to complete their translation on time but user should have chance to download it after the release of it (without waiting for the next tagging ). Wouldn't it be possible to download and install the latest language data in applications just like users do with themes? Thank you Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu yazdı: > As you may know, translations for apps don't live in the same place as the > code for the apps themselves. > > This greatly benefits translators but is not awesome for the release > management > side of things since it means that for each release we need to not forget > to > copy the appropriate files to the appropriate place, makes tagging > somewhat > harder, etc. > > For a while now we have been running an "experimental" copy-po-qm-docbook- > back-to-repository in a number of "select" repositories and it seems to > have > worked quite well, you can seem one example in > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > The idea is to enable this for all repositories. > > This is a heads up, as a developer there's nothing you need to do, at most > remove the po/ folder from .gitignore if for some reason it is there. > > If you're a packager you will need to make sure your scripts don't try to > copy > po/qm/docbook files anymore when doing a release once this is activated. > > My plan would be to enable this scripts over Akademy so we have the high > bandwidth there to fix things if needed. > > Opinions? Comments? > > Cheers, > Albert > > >
Re: Copying po/docbook files to repositories nightly
El dissabte, 3 de setembre de 2022, a les 0:29:34 (CEST), David Edmundson va escriure: > >Opinions? Comments? > > So our releases will end up a 1:1 with a git tag? Yes [*] > That would be > super-duper amazing for many cleanup things, including the security > aspect +1 > > What's the plan for stable branches? > We'll either need to port all active stable branches at the same time > or we will have to make sure releaseme either has multiple branches or > a runtime toggle. Yes, plan is to do everything at once. > > >My plan would be to enable this scripts over Akademy > > FYI: > Plasma beta is tagged Thu 2022-09-22 > Plasma 5.26 is tagged Thu 2022-10-06 > > Akademy is in the middle of those. > I don't see how there can be too much fall-out so it's probably fine, > but if we are expecting lots of fixes to be needed that's not the best > timing from our side. I'd say any fallout should be defenitely be sorted out before October 6th. Cheers, Albert [*] For KDE Gear we still have some fixing to do with the data/ folders https://phabricator.kde.org/T13618 > > David
Re: Copying po/docbook files to repositories nightly
On Sat, Sep 3, 2022 at 9:24 AM Albert Astals Cid wrote: > As you may know, translations for apps don't live in the same place as the > code for the apps themselves. > > This greatly benefits translators but is not awesome for the release > management > side of things since it means that for each release we need to not forget > to > copy the appropriate files to the appropriate place, makes tagging > somewhat > harder, etc. > > For a while now we have been running an "experimental" copy-po-qm-docbook- > back-to-repository in a number of "select" repositories and it seems to > have > worked quite well, you can seem one example in > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po > > The idea is to enable this for all repositories. > > This is a heads up, as a developer there's nothing you need to do, at most > remove the po/ folder from .gitignore if for some reason it is there. > > If you're a packager you will need to make sure your scripts don't try to > copy > po/qm/docbook files anymore when doing a release once this is activated. > > My plan would be to enable this scripts over Akademy so we have the high > bandwidth there to fix things if needed. > > Opinions? Comments? > I'm very happy to see this change finally start to roll out - being something that was last discussed back in MIlian I believe! Looking forward to it rolling out as it will mean we can start including translations in nightly builds and will no longer have such a high release-day load on our systems. > Cheers, > Albert > > > Cheers, Ben
Re: Copying po/docbook files to repositories nightly
On Sat, Sep 3, 2022 at 11:02 AM Ömer Fadıl USTA wrote: > Just wanted to learn one thing , isn't this will populate the logs with > lots of entries on git log history ? > The history already receives a number of commits from scripty relating to updates made to *.desktop files, but yes it will involve additional commits being made. They would only impact po/ and poqm/ folders, which you can be easily excluded if you have a local copy. > I mean right now I am tracking git changes based on changes in history but > this will add a new entry > each night or I understand this wrong ? > It will add a commit each day there is an update to the translations - which may be every night, but is not guaranteed to be the case. > Also wouldn't it be possible to fetch related translation on the fly from > the software side after releases ? > I mean translation of language X might be getting a little back lets say > 5.26 released but team X > might be late to complete their translation on time but user should have > chance to download it > after the release of it (without waiting for the next tagging ). Wouldn't > it be possible to download and install the latest > language data in applications just like users do with themes? > Users currently have to wait for releases to receive updates to translations (among many other things) so this represents no change to what we do currently. Also, from an infrastructural perspective i'm very much opposed to this - and there are numerous corner cases (such as string changes which while rare do happen in stable from time to time) which could lead to various breakages in the software itself. > > Thank you > > Ömer Fadıl Usta > PGP key : 0xfd11561976b1690b > about.me/omerusta > Cheers, Ben > > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu > yazdı: > >> As you may know, translations for apps don't live in the same place as >> the >> code for the apps themselves. >> >> This greatly benefits translators but is not awesome for the release >> management >> side of things since it means that for each release we need to not forget >> to >> copy the appropriate files to the appropriate place, makes tagging >> somewhat >> harder, etc. >> >> For a while now we have been running an "experimental" copy-po-qm-docbook- >> back-to-repository in a number of "select" repositories and it seems to >> have >> worked quite well, you can seem one example in >> https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po >> >> The idea is to enable this for all repositories. >> >> This is a heads up, as a developer there's nothing you need to do, at >> most >> remove the po/ folder from .gitignore if for some reason it is there. >> >> If you're a packager you will need to make sure your scripts don't try to >> copy >> po/qm/docbook files anymore when doing a release once this is activated. >> >> My plan would be to enable this scripts over Akademy so we have the high >> bandwidth there to fix things if needed. >> >> Opinions? Comments? >> >> Cheers, >> Albert >> >> >>
Re: Copying po/docbook files to repositories nightly
>Opinions? Comments? So our releases will end up a 1:1 with a git tag? That would be super-duper amazing for many cleanup things, including the security aspect +1 What's the plan for stable branches? We'll either need to port all active stable branches at the same time or we will have to make sure releaseme either has multiple branches or a runtime toggle. >My plan would be to enable this scripts over Akademy FYI: Plasma beta is tagged Thu 2022-09-22 Plasma 5.26 is tagged Thu 2022-10-06 Akademy is in the middle of those. I don't see how there can be too much fall-out so it's probably fine, but if we are expecting lots of fixes to be needed that's not the best timing from our side. David
Re: Copying po/docbook files to repositories nightly
Sounds like a great idea to me! Nate On 9/2/22 15:24, Albert Astals Cid wrote: As you may know, translations for apps don't live in the same place as the code for the apps themselves. This greatly benefits translators but is not awesome for the release management side of things since it means that for each release we need to not forget to copy the appropriate files to the appropriate place, makes tagging somewhat harder, etc. For a while now we have been running an "experimental" copy-po-qm-docbook- back-to-repository in a number of "select" repositories and it seems to have worked quite well, you can seem one example in https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po The idea is to enable this for all repositories. This is a heads up, as a developer there's nothing you need to do, at most remove the po/ folder from .gitignore if for some reason it is there. If you're a packager you will need to make sure your scripts don't try to copy po/qm/docbook files anymore when doing a release once this is activated. My plan would be to enable this scripts over Akademy so we have the high bandwidth there to fix things if needed. Opinions? Comments? Cheers, Albert
