Copying po/docbook files to repositories nightly

[Ömer Fadıl USTA]

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 <aacid at kde.org>, 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20220903/a6cca7a4/attachment.htm>