[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Copying po/docbook files to repositories nightly
From: Johnny Jazeix <jazeix () gmail ! com>
Date: 2022-09-03 8:44:01
Message-ID: CAEtcAPEiB2XCyB6=_BrF7_yx3WYUgSKNvoX=G=PS8GW=aGPNrA () mail ! gmail ! com
[Download RAW message or body]
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_<lang>.po, not po/<lang>/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 =C3=A0 09:47, Albert Astals Cid <aacid@kde.org> a =C3=
=A9crit :
> El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), =C3=96mer Fad=
=C4=B1l 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 entr=
y
> each night.
>
> Cheers,
> Albert
>
> > Also wouldn't it be possible to fetch related translation on the fly fr=
om
> > the software side after releases ?
> > I mean translation of language X might be getting a little back lets sa=
y
> > 5.26 released but team X
> > might be late to complete their translation on time but user should hav=
e
> > 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
> >
> > =C3=96mer Fad=C4=B1l Usta
> > PGP key : 0xfd11561976b1690b
> > about.me/omerusta
> >
> >
> > Albert Astals Cid <aacid@kde.org>, 3 Eyl 2022 Cmt, 00:25 tarihinde =C5=
=9Funu
> >
> > yazd=C4=B1:
> > > As you may know, translations for apps don't live in the same place a=
s
> 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 tr=
y
> 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
>
>
>
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>Hi,</div><div><br></div><div>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_<lang>.po, not po/<lang>/gcompris_qt.po). \
I'll take a look to harmonise it with the usual.</div><div>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).</div><div><br></div><div>Cheers,</div><div><br></div><div>Johnny<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 3 sept. 2022 Ã \
09:47, Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@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">El dissabte, 3 de \
setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA va <br> escriure:<br>
> Just wanted to learn one thing , isn't this will populate the logs with<br>
> lots of entries on git log history ?<br>
> I mean right now I am tracking git changes based on changes in history but<br>
> this will add a new entry<br>
> each night or I understand this wrong ?<br>
<br>
If you look a the example URL i posted you can see there's not a new entry <br>
each night.<br>
<br>
Cheers,<br>
Albert<br>
<br>
> Also wouldn't it be possible to fetch related translation on the fly \
from<br> > the software side after releases ?<br>
> I mean translation of language X might be getting a little back lets say<br>
> 5.26 released but team X<br>
> might be late to complete their translation on time but user should have<br>
> chance to download it<br>
> after the release of it (without waiting for the next tagging ). \
Wouldn't<br> > it be possible to download and install the latest<br>
> language data in applications just like users do with themes?<br>
> <br>
> Thank you<br>
> <br>
> Ömer Fadıl Usta<br>
> PGP key : 0xfd11561976b1690b<br>
> <a href="http://about.me/omerusta" rel="noreferrer" \
target="_blank">about.me/omerusta</a><br> > <br>
> <br>
> Albert Astals Cid <<a href="mailto:aacid@kde.org" \
target="_blank">aacid@kde.org</a>>, 3 Eyl 2022 Cmt, 00:25 tarihinde ÅŸunu<br> > \
<br> > yazdı:<br>
> > As you may know, translations for apps don't live in the same place as \
the<br> > > code for the apps themselves.<br>
> > <br>
> > This greatly benefits translators but is not awesome for the release<br>
> > management<br>
> > side of things since it means that for each release we need to not \
forget<br> > > to<br>
> > copy the appropriate files to the appropriate place, makes tagging<br>
> > somewhat<br>
> > harder, etc.<br>
> > <br>
> > For a while now we have been running an "experimental" \
copy-po-qm-docbook-<br> > > back-to-repository in a number of \
"select" repositories and it seems to<br> > > have<br>
> > worked quite well, you can seem one example in<br>
> > <a href="https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po" \
rel="noreferrer" target="_blank">https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po</a><br>
> > <br>
> > The idea is to enable this for all repositories.<br>
> > <br>
> > This is a heads up, as a developer there's nothing you need to do, at \
most<br> > > remove the po/ folder from .gitignore if for some reason it is \
there.<br> > > <br>
> > If you're a packager you will need to make sure your scripts don't \
try to<br> > > copy<br>
> > po/qm/docbook files anymore when doing a release once this is \
activated.<br> > > <br>
> > My plan would be to enable this scripts over Akademy so we have the \
high<br> > > bandwidth there to fix things if needed.<br>
> > <br>
> > Opinions? Comments?<br>
> > <br>
> > Cheers,<br>
> > <br>
> > Albert<br>
<br>
<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