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