[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-04 9:32:36
Message-ID: CAEtcAPG4oYB2w0-K=mawi7pNrthgJfHLtn1=-uAYk_zVH7K9xw () mail ! gmail ! com
[Download RAW message or body]
Le dim. 4 sept. 2022 =C3=A0 11:14, Albert Astals Cid <aacid@kde.org> a =C3=
=A9crit :
> 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_<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).
>
> 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 =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 F=
ad=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
> entry
> > > each night.
> > >
> > > Cheers,
> > >
> > > Albert
> > >
> > > > Also wouldn't it be possible to fetch related translation on the fl=
y
> > > > from
> > > > the software side after releases ?
> > > > I mean translation of language X might be getting a little back let=
s
> 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
> > > >
> > > > =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 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 no=
t
> > >
> > > forget
> > >
> > > > > to
> > > > > copy the appropriate files to the appropriate place, makes taggin=
g
> > > > > 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/p=
o
> > > > >
> > > > > 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 t=
he
> > >
> > > high
> > >
> > > > > bandwidth there to fix things if needed.
> > > > >
> > > > > Opinions? Comments?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Albert
>
>
>
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Le dim. 4 sept. 2022 Ã 11:14, 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 10:44:01 \
(CEST), Johnny Jazeix va <br> escriure:<br>
> Hi,<br>
> <br>
> this is great. For GCompris, we have some stuff to handle translation that<br>
> differs from the usual (for example, the po files are in<br>
> po/gcompris_<lang>.po, not po/<lang>/gcompris_qt.po). I'll take \
a look to<br> > harmonise it with the usual.<br>
> For the stable branch, we don't plan to do a release before December so \
it<br> > would be better to not apply it at Akademy (except if the change on<br>
> GCompris side is easily backportable but I have to check).<br>
<br>
If you don't plan to do a release before December you have 3 months to make <br>
sure it works, i don't understand the problem.<br>
<br>
Albert<br>
<br></blockquote><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>So yes, the work to do is defined, the \
available time, less.</div><div><br></div><div>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).<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Johnny<br></div><div><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> > <br>
> Cheers,<br>
> <br>
> Johnny<br>
> <br>
> Le sam. 3 sept. 2022 Ã 09:47, Albert Astals Cid <<a \
href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> a écrit :<br> > \
> El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA<br> \
> > va<br> > > <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<br> > > <br>
> > but<br>
> > <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>
> > <br>
> > Albert<br>
> > <br>
> > > Also wouldn't it be possible to fetch related translation on the \
fly<br> > > > 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 ).<br>
> > > 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<br> > > <br>
> > the<br>
> > <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<br> > > <br>
> > forget<br>
> > <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"<br> > > <br>
> > copy-po-qm-docbook-<br>
> > <br>
> > > > back-to-repository in a number of "select" repositories \
and it seems<br> > > > > 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<br> > > <br>
> > most<br>
> > <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<br> > > <br>
> > to<br>
> > <br>
> > > > copy<br>
> > > > po/qm/docbook files anymore when doing a release once this is<br>
> > <br>
> > activated.<br>
> > <br>
> > > > My plan would be to enable this scripts over Akademy so we have \
the<br> > > <br>
> > high<br>
> > <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></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic