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/
