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
> >>> <https://invent.kde.org/documentation/docs-krita-org/-/tree/krita/5.1>.
> >>> 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/