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