Re: Effort to reduce translatable strings in debian-edu-doc manuals
Hi
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?
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.
* all translation copyright notices and credits are dropped from the manual
source and from all the generated manuals.
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.
* 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.
Perhaps other schemes are conceivable too. Depending on the chosen scheme,
the possible technical solutions could differ, as I see it.
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?
Frans
Reply to: