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 deb...@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/
signature.asc
Description: Digital signature