Hi Wolfgang, Wolfgang Schweer schreef op di 04-08-2020 om 23:11 [+0200]: > Hi Frans, > > > The place will be the related Po4a addendum file. In case a new PO > translation file is added, the addendum file needs to be created - using > an existing one as sample.
Ok. I'll try and keep this in mind when updating translations made via weblate. > > > > > I think working with an .add file is the way to go. It would be great > > if > > you could realize this. > > Done now, the manuals including translater credits are here: > https://jenkins.debian.net/userContent/debian-edu-doc/ Cool. This looks very good. I am very impressed with the speed with which you have accomplished this. > > > In a initial stage, I agree that it will be easiest to edit those .add > > files on our own. However, I can imagine that for some languages native > > speakers would find the wording 'Authors of the translation' a bit > > suboptimal. > > Yes, thanks for the hint; I've reduced this to 'Translation:' > > > Maybe in the future we could find a way to add > > > > #. type: Content of: <article><addendum><para> > > msgid "The following persons contributed to the translation of this > > manual:" > > msgstr "" > > > > as a final string at the end of the debian-edu-xxx-manual.pot of the > > testing release, so that native speakers could provide a sentence that > > feels good in their language. > > But for the moment I don't see how this could be integrated in the > > current > > proces of building the manual without to much hassle. > > I suspect that integration into debian-edu-xxx-manual.pot won't be > possible like that - at least to my understanding. Of course, those > translators using Git can use a more verbose stanza. I understand. I was thinking about such a method out of my concern that with languages about which we do not have any knowledge at all, it is difficult to estimate what could be a good wording for that language. Therefore I was looking for a method to have input from native speakers. But with the concise wording "translators", there is probably little chance of making a mistake here. > > > > The procedure for the Bullseye manual is different from the > > > one for the legacy manuals (Audacity, Buster, ITIL, Rosegarden). > > This difference shows up in XML <section>, where the Bullseye manual is > missing id='xx' as opposed to the legacy ones. Reason for this due to > the fact that the Docbook export from wiki.debian.org changed after the > system running the wiki has been updated to Buster (iirc). I see. I noticed the difference when looking at scripts/get_manual. > > > I would be in favour of building a debian-edu-doc-xx binary with the > > manuals for the current and the previous release and a debian-edu-doc- > > legacy-xx binary with the manuals whose content is no longer updated. > > Outdated documentation that is no longer actively maintained, rapidly > > collects documentation-bitrot and that creates a negative image for the > > whole project. With a legacy binary this could be avoided, without > > dropping > > those manuals entirely. And if someone ever would step in to update the > > content of one of those manuals again, that manual could easily > > reintegrate > > the debian-edu-doc binary. In the meantime I would even be in favour of > > no > > longer actively present those manuals for translation. > > Agreed, that sounds like something to be considered. > > > PS: I'am fine with starting new threads, should we feel the need to > > discuss > > certain aspects a bit more in depth. > > Yes, maybe separate the filtering and binary package issues? Agreed. Frans
