Hi Frans, [ Frans Spiesschaert ] > > > But in between these two widely differing schemes, others were also > > > mentioned, without however being clearly specified. > > > > > > One could for instance think of: [..] > > > * the manual source includes no translation copyright notices and > > > credits, > > > but the translated documents do have a specific translation copyright > > > notice and credits that is applicable to their own language, while the > > > English manual only has general copyright information and no copyright > > > information about translations at all. [ Wolfgang Schweer ] > > Yes, that's what I would prefer. [ Frans Spiesschaert ] > For me, the other three schemes are acceptable. So I'm fine with choosing > this one. > Maybe now we should wait a few days before continuing on this track, so > that also other people have the possibility to give their opinion, if they > want to do so. No one jumped in, so let's continue. [ Frans Spiesschaert ] > > > 2. debian/copyright now depends on the actual scheme in use. So, if we > > > should move away from it, this would affect the generation of that > > > file. > > > Is it important to take this relationship into account while choosing a > > > scheme, or can we easily disregard this? [ Wolfgang Schweer ] > > Agreed. The debian/copyright file wouldn't mention translators so > > need to be generated differently. 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. [ Frans Spiesschaert ] > At this moment it isn't clear to me what practical consequences we will > have to face here. But I suppose we will be able to tackle them when > needed. Yes, that should be doable. 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? As far as further reductions of translatable strings are concerned, I'm undecided. The procedure for the Bullseye manual is different from the one for the legacy manuals (Audacity, Buster, ITIL, Rosegarden). Also, besides typo and URL fixes (and some general information adjustments), the actual content of some manuals is unchanged (and thus in parts outdated) - since 2006 (ITIL), 2008 (Rosegarden) resp. 2009 (Audacity, coming even with the remark: This work in progress will become an Audacity manual). I have no real clue about about the Rosegarden and Audacity programs and dont't know enough about history and purpose of the existing manuals, but it seems that the manuals provided by both projects might be a more useful source of information. Wolfgang
Attachment:
signature.asc
Description: PGP signature