Hi Frans, [ Frans Spiesschaert, 2020-08-03 ] > > [ Wolfgang Schweer ] > > As the translator names will be listed in po4a addendum files, copyright > > information for both PO and ADD files would need to be added to the > > debian/copyright.packaging file, I guess. > > Right. But where should we collect the translator's names in the first > place? When a new translator steps in now, I add his/her name in the > CopyRight section of the manual on the wiki. But in the future that section > will disappear, at least the "Translation copyright and authors" part of > it. So we will need to collect the source data on translators elsewhere. 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. > > I could provide all ADD files and an adjusted debian/copyright.packaging > > file, as well as adjusted po4a.cfg matching each manual in a single > > commit. > > This way, reverting the changes would be easier. > > > > What do you think about it? > > 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/ > 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. > > As far as further reductions of translatable strings are concerned, I'm > > undecided. > > When I look at the "README for translators" in documentation/common/, it > says "Don't translate FIXMEs, URLs, image file names, etc.". > Because a random translator passing by at weblate does not have that > information, I would like to investigate how far we could get in filtering > out those elements with the pot_in feature of po4a. Agreed. > > 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 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? Wolfgang
Attachment:
signature.asc
Description: PGP signature