Re: Effort to reduce translatable strings in debian-edu-doc manuals
Hi Wolfgang,
Wolfgang Schweer schreef op zo 02-08-2020 om 23:30 [+0200]:
> Hi Frans,
>
> No one jumped in, so let's continue.
Right. I hope Holger will shout loudly when something goes wrong in his
opinion.
>
> [ 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.
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.
>
> [ 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?
I think working with an .add file is the way to go. It would be great if
you could realize 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. 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.
>
> 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.
> 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 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.
>
> 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
PS: I'am fine with starting new threads, should we feel the need to discuss
certain aspects a bit more in depth.
--
Kind regards,
Frans Spiesschaert
Reply to: