Re: Copying po/docbook files to repositories nightly

[Albert Astals Cid]

El dilluns, 10 d’octubre de 2022, a les 22:00:59 (CEST), Albert Astals Cid va 
escriure:
> El dilluns, 10 d’octubre de 2022, a les 15:03:14 (CEST), Alvin Wong va
> 
> escriure:
> > Hi,
> > 
> > On 10/10/2022 5:20, Albert Astals Cid wrote:
> > > El divendres, 7 d’octubre de 2022, a les 23:07:38 (CEST), Albert Astals
> > > Cid va>
> > > 
> > > escriure:
> > >> El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va
> > >> 
> > >> escriure:
> > >>> Hi,
> > >>> 
> > >>> I notice this has been applied to docs-krita-org
> > >>> 
> > >>> .
> > >>> However, being a Sphinx doc project it already has a
> > >>> `StaticMessages.sh`
> > >>> script to copy the PO files into the `locale/` directory and
> > >>> "unflatten"
> > >>> the directory layout to what the Sphinx build expects (the files in
> > >>> the
> > >>> l10n SVN tree have the directory layout flattened by mangling the
> > >>> filenames). Now the files are also being copied to the `po/`
> > >>> directory,
> > >>> but
> > >>> in the flattened layout, which in practice are unused duplicated
> > >>> copies.
> > >>> Should we opt-out of this copying step to avoid the duplicated files,
> > >>> or
> > >>> is
> > >>> there a better way to handle this?
> > >> 
> > >> We will make it so that for StaticMessages.sh the po files are not
> > >> copied
> > >> back.
> > > 
> > > So we kind of fixed that but that didn't work for your use case because
> > > you're using the EXPORTS_POT_DIR=1 "special" use case
> > > 
> > > The gist of the "fix" we did is that we don't copy back to the git repo
> > > the
> > > files that end in _static_.po
> > > 
> > > Would able to adapt your StaticMessages.sh so that's the suffix of the
> > > files being generated?
> > > 
> > > Cheers,
> > > 
> > >Albert
> > 
> > I am not sure we want to change the file names of almost 300 .pot files
> > which may be disrupting to translators.
> 
> File renaming will be [mostly] transparent for translators, hardly any
> disruption at all.

Forgot to say. You need to tell us when you do the renaming so we rename all 
existing files.

Also the po/ fix you suggested would also work, i feel it's non optimal but if 
you prefer to do that it's also acceptable if you documented it well in the 
.gitignore for future ourselves to remember why it's there.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > Will it be a better idea to just
> > remove the `po/` directory and add it to `.gitignore`?
> > 
> > Best Regards,
> > Alvin
> > 
> > >>> By the way, it seems the existing `StaticMessages.sh` copy step is
> > >>> slightly
> > >>> out of sync with the new copy step (the git commits don't have
> > >>> identical
> > >>> diff contents). Is this something to be concerned about?
> > >> 
> > >> Can you point me to such discrepancy?
> > >> 
> > >> Cheers,
> > >> 
> > >>Albert
> > >>> 
> > >>> Best Regards,
> > >>> Alvin
> > >>> 
> >  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/p
> > > o
> > > />//>/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. 

Re: Copying po/docbook files to repositories nightly

[Albert Astals Cid]

El dilluns, 10 d’octubre de 2022, a les 15:03:14 (CEST), Alvin Wong va 
escriure:
> Hi,
> 
> On 10/10/2022 5:20, Albert Astals Cid wrote:
> > El divendres, 7 d’octubre de 2022, a les 23:07:38 (CEST), Albert Astals
> > Cid va> 
> > escriure:
> >> El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va
> >> 
> >> escriure:
> >>> Hi,
> >>> 
> >>> I notice this has been applied to docs-krita-org
> >>> .
> >>> However, being a Sphinx doc project it already has a `StaticMessages.sh`
> >>> script to copy the PO files into the `locale/` directory and "unflatten"
> >>> the directory layout to what the Sphinx build expects (the files in the
> >>> l10n SVN tree have the directory layout flattened by mangling the
> >>> filenames). Now the files are also being copied to the `po/` directory,
> >>> but
> >>> in the flattened layout, which in practice are unused duplicated copies.
> >>> Should we opt-out of this copying step to avoid the duplicated files, or
> >>> is
> >>> there a better way to handle this?
> >> 
> >> We will make it so that for StaticMessages.sh the po files are not copied
> >> back.
> > 
> > So we kind of fixed that but that didn't work for your use case because
> > you're using the EXPORTS_POT_DIR=1 "special" use case
> > 
> > The gist of the "fix" we did is that we don't copy back to the git repo
> > the
> > files that end in _static_.po
> > 
> > Would able to adapt your StaticMessages.sh so that's the suffix of the
> > files being generated?
> > 
> > Cheers,
> > 
> >Albert
> 
> I am not sure we want to change the file names of almost 300 .pot files
> which may be disrupting to translators. 

File renaming will be [mostly] transparent for translators, hardly any 
disruption at all.

Cheers,
  Albert

> Will it be a better idea to just
> remove the `po/` directory and add it to `.gitignore`?
> 
> Best Regards,
> Alvin
> 
> >>> By the way, it seems the existing `StaticMessages.sh` copy step is
> >>> slightly
> >>> out of sync with the new copy step (the git commits don't have identical
> >>> diff contents). Is this something to be concerned about?
> >> 
> >> Can you point me to such discrepancy?
> >> 
> >> Cheers,
> >> 
> >>Albert
> >>> 
> >>> Best Regards,
> >>> Alvin
> >>> 
>  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

[Alvin Wong]

Hi,

On 10/10/2022 5:20, Albert Astals Cid wrote:

El divendres, 7 d’octubre de 2022, a les 23:07:38 (CEST), Albert Astals Cid va
escriure:

El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va

escriure:

Hi,

I notice this has been applied to docs-krita-org
.
However, being a Sphinx doc project it already has a `StaticMessages.sh`
script to copy the PO files into the `locale/` directory and "unflatten"
the directory layout to what the Sphinx build expects (the files in the
l10n SVN tree have the directory layout flattened by mangling the
filenames). Now the files are also being copied to the `po/` directory,
but
in the flattened layout, which in practice are unused duplicated copies.
Should we opt-out of this copying step to avoid the duplicated files, or
is
there a better way to handle this?

We will make it so that for StaticMessages.sh the po files are not copied
back.

So we kind of fixed that but that didn't work for your use case because you're
using the EXPORTS_POT_DIR=1 "special" use case

The gist of the "fix" we did is that we don't copy back to the git repo the
files that end in _static_.po

Would able to adapt your StaticMessages.sh so that's the suffix of the files
being generated?

Cheers,
   Albert


I am not sure we want to change the file names of almost 300 .pot files 
which may be disrupting to translators. Will it be a better idea to just 
remove the `po/` directory and add it to `.gitignore`?


Best Regards,
Alvin



By the way, it seems the existing `StaticMessages.sh` copy step is
slightly
out of sync with the new copy step (the git commits don't have identical
diff contents). Is this something to be concerned about?

Can you point me to such discrepancy?

Cheers,
   Albert


Best Regards,
Alvin


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

[Albert Astals Cid]

El divendres, 7 d’octubre de 2022, a les 23:07:38 (CEST), Albert Astals Cid va 
escriure:
> El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va
> 
> escriure:
> > Hi,
> > 
> > I notice this has been applied to docs-krita-org
> > .
> > However, being a Sphinx doc project it already has a `StaticMessages.sh`
> > script to copy the PO files into the `locale/` directory and "unflatten"
> > the directory layout to what the Sphinx build expects (the files in the
> > l10n SVN tree have the directory layout flattened by mangling the
> > filenames). Now the files are also being copied to the `po/` directory,
> > but
> > in the flattened layout, which in practice are unused duplicated copies.
> > Should we opt-out of this copying step to avoid the duplicated files, or
> > is
> > there a better way to handle this?
> 
> We will make it so that for StaticMessages.sh the po files are not copied
> back.

So we kind of fixed that but that didn't work for your use case because you're 
using the EXPORTS_POT_DIR=1 "special" use case

The gist of the "fix" we did is that we don't copy back to the git repo the 
files that end in _static_.po 

Would able to adapt your StaticMessages.sh so that's the suffix of the files 
being generated?

Cheers,
  Albert

> > By the way, it seems the existing `StaticMessages.sh` copy step is
> > slightly
> > out of sync with the new copy step (the git commits don't have identical
> > diff contents). Is this something to be concerned about?
> 
> Can you point me to such discrepancy?
> 
> Cheers,
>   Albert
> 
> > Best Regards,
> > Alvin
> > 
> > > 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

[Albert Astals Cid]

El dissabte, 8 d’octubre de 2022, a les 11:19:41 (CEST), Alvin Wong va 
escriure:
> Hi,
> 
> On 8/10/2022 5:07, Albert Astals Cid wrote:
> > El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va
> > 
> > escriure:
> >> Hi,
> >> 
> >> I notice this has been applied to docs-krita-org
> >> .
> >> However, being a Sphinx doc project it already has a `StaticMessages.sh`
> >> script to copy the PO files into the `locale/` directory and "unflatten"
> >> the directory layout to what the Sphinx build expects (the files in the
> >> l10n SVN tree have the directory layout flattened by mangling the
> >> filenames). Now the files are also being copied to the `po/` directory,
> >> but
> >> in the flattened layout, which in practice are unused duplicated copies.
> >> Should we opt-out of this copying step to avoid the duplicated files, or
> >> is
> >> there a better way to handle this?
> > 
> > We will make it so that for StaticMessages.sh the po files are not copied
> > back.
> Thanks.
> 
> >> By the way, it seems the existing `StaticMessages.sh` copy step is
> >> slightly
> >> out of sync with the new copy step (the git commits don't have identical
> >> diff contents). Is this something to be concerned about?
> > 
> > Can you point me to such discrepancy?
> 
> For example, compare the last `StaticMessages.sh` update "made messages
> (after extraction)"
>  26f2ff4860374da440544a88ea> and the last PO copy change "Sync po/docbooks
> with svn"
>  de6940153720f457d1bc96df6d>, the list of changed files are different. The
> commit "Sync po/docbooks with svn" changed
> `po/ca/docs_krita_org_contributors_manual___krita_manual_conventions.po`
> with the POT creation date updated to "2022-10-08", while "made messages
> (after extraction)" did not change
> `locale/ca/LC_MESSAGES/contributors_manual/krita_manual_conventions.po`
> -- at this commit, this file still has a POT creation date of
> "2022-10-04"
>  6940153720f457d1bc96df6d/locale/ca/LC_MESSAGES/contributors_manual/krita_man
> ual_conventions.po>.

That's fine, the different is one is pre-msgmerge and the other post-msgmerge, 
but you get "the same translations" in both.

Cheers,
  Albert

> 
> Best Regards,
> Alvin
> 
> > Cheers,
> > 
> >Albert
> >> 
> >> Best Regards,
> >> Alvin
> >> 
> >>> 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

[Alvin Wong]

Hi,

On 8/10/2022 5:07, Albert Astals Cid wrote:

El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va
escriure:

Hi,

I notice this has been applied to docs-krita-org
.
However, being a Sphinx doc project it already has a `StaticMessages.sh`
script to copy the PO files into the `locale/` directory and "unflatten"
the directory layout to what the Sphinx build expects (the files in the
l10n SVN tree have the directory layout flattened by mangling the
filenames). Now the files are also being copied to the `po/` directory, but
in the flattened layout, which in practice are unused duplicated copies.
Should we opt-out of this copying step to avoid the duplicated files, or is
there a better way to handle this?

We will make it so that for StaticMessages.sh the po files are not copied back.


Thanks.


By the way, it seems the existing `StaticMessages.sh` copy step is slightly
out of sync with the new copy step (the git commits don't have identical
diff contents). Is this something to be concerned about?

Can you point me to such discrepancy?


For example, compare the last `StaticMessages.sh` update "made messages 
(after extraction)" 
 
and the last PO copy change "Sync po/docbooks with svn" 
, 
the list of changed files are different. The commit "Sync po/docbooks 
with svn" changed 
`po/ca/docs_krita_org_contributors_manual___krita_manual_conventions.po` 
with the POT creation date updated to "2022-10-08", while "made messages 
(after extraction)" did not change 
`locale/ca/LC_MESSAGES/contributors_manual/krita_manual_conventions.po` 
-- at this commit, this file still has a POT creation date of 
"2022-10-04" 
.


Best Regards,
Alvin



Cheers,
   Albert


Best Regards,
Alvin


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

[Albert Astals Cid]

El dimecres, 5 d’octubre de 2022, a les 18:59:08 (CEST), Alvin Wong va 
escriure:
> Hi,
> 
> I notice this has been applied to docs-krita-org
> .
> However, being a Sphinx doc project it already has a `StaticMessages.sh`
> script to copy the PO files into the `locale/` directory and "unflatten"
> the directory layout to what the Sphinx build expects (the files in the
> l10n SVN tree have the directory layout flattened by mangling the
> filenames). Now the files are also being copied to the `po/` directory, but
> in the flattened layout, which in practice are unused duplicated copies.
> Should we opt-out of this copying step to avoid the duplicated files, or is
> there a better way to handle this?

We will make it so that for StaticMessages.sh the po files are not copied back.

> By the way, it seems the existing `StaticMessages.sh` copy step is slightly
> out of sync with the new copy step (the git commits don't have identical
> diff contents). Is this something to be concerned about?

Can you point me to such discrepancy?

Cheers,
  Albert

> 
> Best Regards,
> Alvin
> 
> > 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

[Alvin Wong]

Hi,

I notice this has been applied to docs-krita-org 
. 
However, being a Sphinx doc project it already has a `StaticMessages.sh` script 
to copy the PO files into the `locale/` directory and "unflatten" the directory 
layout to what the Sphinx build expects (the files in the l10n SVN tree have 
the directory layout flattened by mangling the filenames). Now the files are 
also being copied to the `po/` directory, but in the flattened layout, which in 
practice are unused duplicated copies. Should we opt-out of this copying step 
to avoid the duplicated files, or is there a better way to handle this?

By the way, it seems the existing `StaticMessages.sh` copy step is slightly out 
of sync with the new copy step (the git commits don't have identical diff 
contents). Is this something to be concerned about?

Best Regards,
Alvin

> 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

[Albert Astals Cid]

El dilluns, 3 d’octubre de 2022, a les 19:07:12 (CEST), Tobias Leupold va 
escriure:
> Am Montag, 3. Oktober 2022, 15:47:15 CEST schrieb Albert Astals Cid:
> > El dilluns, 3 d’octubre de 2022, a les 15:38:29 (CEST), Albert Astals Cid
> > va> 
> > escriure:
> > > El diumenge, 2 d’octubre de 2022, a les 17:57:10 (CEST), Johannes
> > > Zarl-Zierl>
> > > 
> > > va escriure:
> > > > Hi Albert,
> > > > 
> > > > Thanks for the change !
> > > > 
> > > > Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid:
> > > > > 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.
> > > > 
> > > > I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks
> > > > with
> > > > svn" commit did land in our repo and po is not listed in our
> > > > .gitignore.
> > > 
> > > It seems I failed reporting kphotoalbum, apologies.
> > 
> > Actually no I was right, the .gitignore has
> > 
> >   kphotoalbum
> > 
> > in it
> > 
> > which is making git ignore the
> > 
> >po/language/docs/kphotoalbum
> > 
> > folders.
> 
> Hey Albert,
> 
> Thanks for pointing this out!
> 
> I think this is a remnant from old times where we didn't build inside of a
> "build/" directory. Which is possibly also the case for most of the other
> entries in .gitignore, but that's another thing.
> 
> I hope I fixed this with commit ab87cf51, is it okay now?

Looks good :)

> 
> Tobias
> 
> > 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.
> > > > 
> > > > Should I add "ki18n_install(po)" to my CMakeLists.txt?
> > > 
> > > Yes, well  no because Christophe already added it.
> > > 
> > > Cheers,
> > > 
> > >   Albert
> > >   
> > > > Cheers,
> > > > 
> > > >   Johannes

Re: Copying po/docbook files to repositories nightly

[Tobias Leupold]

Am Montag, 3. Oktober 2022, 15:47:15 CEST schrieb Albert Astals Cid:
> El dilluns, 3 d’octubre de 2022, a les 15:38:29 (CEST), Albert Astals Cid va
> escriure:
> > El diumenge, 2 d’octubre de 2022, a les 17:57:10 (CEST), Johannes
> > Zarl-Zierl> 
> > va escriure:
> > > Hi Albert,
> > > 
> > > Thanks for the change !
> > > 
> > > Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid:
> > > > 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.
> > > 
> > > I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with
> > > svn" commit did land in our repo and po is not listed in our .gitignore.
> > 
> > It seems I failed reporting kphotoalbum, apologies.
> 
> Actually no I was right, the .gitignore has
>   kphotoalbum
> in it
> 
> which is making git ignore the
>po/language/docs/kphotoalbum
> folders.

Hey Albert,

Thanks for pointing this out!

I think this is a remnant from old times where we didn't build inside of a 
"build/" directory. Which is possibly also the case for most of the other 
entries in .gitignore, but that's another thing.

I hope I fixed this with commit ab87cf51, is it okay now?

Tobias

> 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.
> > > 
> > > Should I add "ki18n_install(po)" to my CMakeLists.txt?
> > 
> > Yes, well  no because Christophe already added it.
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > Cheers,
> > > 
> > >   Johannes

Re: Copying po/docbook files to repositories nightly

[Albert Astals Cid]

El dilluns, 3 d’octubre de 2022, a les 15:38:29 (CEST), Albert Astals Cid va 
escriure:
> El diumenge, 2 d’octubre de 2022, a les 17:57:10 (CEST), Johannes Zarl-Zierl
> va escriure:
> > Hi Albert,
> > 
> > Thanks for the change !
> > 
> > Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid:
> > > 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.
> > 
> > I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with
> > svn" commit did land in our repo and po is not listed in our .gitignore.
> 
> It seems I failed reporting kphotoalbum, apologies.

Actually no I was right, the .gitignore has
  kphotoalbum
in it

which is making git ignore the 
   po/language/docs/kphotoalbum
folders.

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.
> > 
> > Should I add "ki18n_install(po)" to my CMakeLists.txt?
> 
> Yes, well  no because Christophe already added it.
> 
> Cheers,
>   Albert
> 
> > Cheers,
> > 
> >   Johannes

Re: Copying po/docbook files to repositories nightly

[Albert Astals Cid]

El diumenge, 2 d’octubre de 2022, a les 17:57:10 (CEST), Johannes Zarl-Zierl 
va escriure:
> Hi Albert,
> 
> Thanks for the change !
> 
> Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid:
> > 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.
> 
> I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with
> svn" commit did land in our repo and po is not listed in our .gitignore.

It seems I failed reporting kphotoalbum, apologies.

> > > > 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.
> 
> Should I add "ki18n_install(po)" to my CMakeLists.txt?

Yes, well  no because Christophe already added it.

Cheers,
  Albert

> 
> Cheers,
>   Johannes

Re: Copying po/docbook files to repositories nightly

[Johannes Zarl-Zierl]

Hi Albert,

Thanks for the change !

Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid:
> 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.

I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with svn" 
commit did land in our repo and po is not listed in our .gitignore.

> > > 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.

Should I add "ki18n_install(po)" to my CMakeLists.txt?

Cheers,
  Johannes

Re: Copying po/docbook files to repositories nightly

[Johnny Jazeix]

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

[Albert Astals Cid]

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

[Albert Astals Cid]

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

[Johnny Jazeix]

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

[Albert Astals Cid]

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

[Johnny Jazeix]

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

[Albert Astals Cid]

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

[Albert Astals Cid]

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

[Ben Cooksley]

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

[Ben Cooksley]

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

[Ö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 , 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

[David Edmundson]

>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

Copying po/docbook files to repositories nightly

[Albert Astals Cid]

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