[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Effort to reduce translatable strings in debian-edu-doc manuals



Hi Wolfgang,

Thanks for your reply.

Wolfgang Schweer schreef op ma 27-07-2020 om 19:35 [+0200]:
> Hi Frans,
> 
> On Mon, Jul 27, 2020 at 06:31:19PM +0200, Frans Spiesschaert wrote:
> > Wolfgang Schweer schreef op ma 27-07-2020 om 00:00 [+0200]:
> > 
> > > It's actually quite easy to create those $lang.add files without 
> > > involving translators because only two strings need to be
> > > translated, 
> > > with the translation already contained in the related PO file. Let
> > > me 
> > > try to explain this using the content of the 
> > > debian-edu-bullseye-manual.nb.add file as an example:
> > 
> > I am unsure how to comment on this, because I am confused about a few
> > preliminary questions I have:
> > 
> > 1. what scheme exactly do we consider as the most preferable scheme for
> > the
> > future with regard to translation credits?
> 
> Thanks for raising these questions.
>  
> > As far as I understand, different schemes have been mentioned already,
> > such
> > as:
> > 
> > * translation copyright notices and credits for all languages that have
> > a
> > translation for a certain manual (let's say debian-edu-bullsaye manual)
> > are
> > included in the source (AllInOne.xml) of that manual and in all the
> > generated manuals.
> > This is the scheme that is in use now.
> 
> Right. I propose to change it. That's why I referred to the 
> debian/copyright file of other comparable packages like e.g. 
> debian-reference. No translators mentioned, see:
> https://salsa.debian.org/debian/developers-reference/-/raw/master/debian/copyright
> 
> > * all translation copyright notices and credits are dropped from the
> > manual
> > source and from all the generated manuals.
> 
> That's possible, but wouldn't honor the hard work of translators.

I would regret choosing this scheme.

> 
> > 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 all translation copyright notices and
> > credits
> > for all languages that have a translation, but the translated documents
> > only have that specific translation copyright notice and credits that
> > is
> > applicable to their own language.
> 
> That would force us to continue editing the wikis like before...
> Adding people having translated a few strings via Weblate and thus 
> listing also translations that are not published at all.
> 
> Also, compare it to a book translated from English into twenty other 
> languages. There's probably a hint somewhere about the number of 
> translations, but the English edition won't mention translator names. 
> The Spanish edition would mention the person that did the Spanish
> translation, though.
> 
> > * 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.
> 
> Yes, that's what I would prefer.

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.


>  
> > Perhaps other schemes are conceivable too. Depending on the chosen
> > scheme,
> > the possible technical solutions could differ, as I see it.
> 
> Right, solutions would differ.
>  
> > 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?
> 
> Agreed. The debian/copyright file wouldn't mention translators so need
> to 
> be generated differently.

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.

Frans


Reply to: