[Debian-l10n-devel] Bug#562708: [Debian-ha-maintainers] Bug#562708: redhat-cluster: Superflous space in Debconf template

Helge Kreutzmann debian at helgefjell.de
Mon Jan 4 17:31:27 UTC 2010


Hello,
On Mon, Jan 04, 2010 at 03:57:23PM +0100, Nicolas François wrote:
> However, translators usually use (and should use) the pages such as
> http://www.debian.org/international/l10n/po-debconf/fr
> It would be more difficult to merge there the information from experimental
> without:
>  * a single way of handling experimental by maintainer
>  * an hard coded list (resp. blacklist) of packages for which the data
>    from experimental should be merged (resp. should not be merged)
> I've seen experimental used by some maintainers to start packaging a new
> upstream version while the branch in unstable still evolve for a long
> time, and where the translatable content in experimental is not ready at
> all (and not really taken care of at that time).

This is IMHO very important. Many translation teams have severly
limited man power but still strive to attempt complete translations.
If they would start tracking those experimental versions then other
stuff would remain untranslated.

I would favor that translators come into play once the template has
stabilized and is "production ready". So maybe experimental is good to
fiddle out all upgrade paths (including corner cases) and their
respective debconf quetions and then, possibly after a review on
debian-l10n-english, translators could jump in.

> Another idea could be to indicate (with a small character/icon) in the
> pages like http://www.debian.org/international/l10n/po-debconf/fr that an
> experimental package (with an higher version) exists with an incomplete
> translation (and the package would be raised in its list, as are the
> packages with errors currently).

The first is on its own useless. How do I (as a translator) know what
I should do? Should I rush out to translate this template just to find
out a few releases later that again almost all strings have changed?
Or wouldn't it be wise to spread the wisdom that translators should be
notified with the debconf-po-tools, once the maintainer thinks the
templates are ready? Then those maintainers who do use experiemental
could, once they are satisfied with the templates, just request new
updates while for the remaining, unstable using ones, the current
(established) workflow persists.

The second suggestion I strongly object. For packages with errors it
is wise for teams to check for the cause and possibly do something
about it. For packages with newer templates in experimental it is
quite the opposite - without further information they do not know the
status of the template. Maybe the maintainer just started to write it
(cf. previous paragraph)? At least by name experimental indicates
"experiments", and speaking as a maintainer I might quite well explore
various possibilities (and templates) to find the solution I'm going
to use in unstable and beyond.

> This would let the final decision to a human being, which would make me
> more comfortable currently.

Quite the contrary to me. We should not ask each and every translator
to ask himself if those packages should be translated already. I've no
problems having a separate page[1] where "idle" teams could look at
possible future templates, but the main page should stick to the
templates "in operation".

Greetings

               Helge

[1] With a clear note about their volatile nature.
-- 
      Dr. Helge Kreutzmann                     debian at helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-l10n-devel/attachments/20100104/486a91f0/attachment.pgp>


More information about the Debian-l10n-devel mailing list