Peter Krefting <peter@xxxxxxxxxxxxxxxx> writes: > Should it also be merged into the git.git repository as well, so that > translation can be synced with the upstream version? The problem with > an external project is that it is easy to forget about. Carrying an extra tree that has been (and I suspect will continue to be) managed in a separate workflow and by a separate group does incur coordination cost. > Looks like I had cloned the repo and intended to do a Swedish > translation back in 2019, but never got around to. I guess the lack of > visibility made me forget all about it. It is exactly why you are seeing a proposed solution to raise the visibility that is much lightweight and has less chance of doing unnecessary harm than merging of the project into ours. The help the would-be translators need will be there. To end-users, I do not think it matters in today's world where the manpages come from. The distro folks are there to absorb different ways translated manual pages are done by different projects, and I can hardly believe that our project is in any way unique. I would like to hear from Jean-Noël how the manpage translation project wants to proceed. I do not fundamentally object to taking an approach similar to the one we use to manage the po/ part of our project, where I can normally be unaware of what happens in that directory and leave it to i18n coordinator, but I have a feeling that even such a light-weight integration might affect their workflows at the manpage translation project side, which may or may not be acceptable on their end. Also to go from the work product they have to what our "make -C Documentation all" produces, it may require more build dependencies (like a version of po4a with a patch or two that are yet to be accepted by the upstream), plus updates to Documentation/Makefile, on our side, which might turn out to be an overly high cost relative to the benefits both projects gain. These unknowns need to be resolved before we consider heavier proposals. Thanks.
