Hi, Marc Haber wrote: > On Wed, Jan 02, 2019 at 12:29:50PM +0900, Ansgar Burchardt wrote:
>> I hereby propose to drop section 1.6 Translations and the following >> sentence: "When translations of this document into languages other >> than English disagree with the English text, the English text takes >> precedence." [...] > Please don't do this. While appreciating the effort the translators > make to improve Debian's useability, the quality of the translations is > sometimes bordering on sounding like satire. I cannot judge for any > other languages than German though. > > Policy being a technical document, and most, if not all technical things > in Debian require some proficiency in English, I'd instead propose > dropping translations for Policy and other documents that are targeted > at developers and package maintainers. > > It is important to have (good!) translations for users, the effort going > into translating developer-only documents should better go in our user's > direction. Thanks to both of you for helping frame this discussion. Section 1.6 of policy is interesting to me for other reasons. Its function is to make Debian policy usable as a normative document. That leads me in a few directions: 1. There is no reason in principle that policy in another language could not serve just as well in that capacity, as long as it is of sufficient quality and well reviewed. We could change this section to list criteria for a version of policy to have normative status --- e.g. a. in a language understood by at least one of the policy editors b. unilateral changes to that version are only made by policy editors or their explicit delegates c. non-unilateral changes following the usual process of review on the policy list to gather seconds from a Debian Developer 2. There is something very idealistic about treating policy as a standards document. In practice, even in English, it has not been air-tight enough for that, and has worked best as a part of a system that includes the ability to get help interpreting it from the policy list. In that context, would removing section 1.6 be so bad? We could add a note to section 1.1 to help people parsing standardeses to understand the best way to resolve confusing or ambiguous passages: instead of trying to read deeply into confusing language, file a bug and work with release managers and/or policy editors to get it clarified. 3. I would be against removing section 1.6 without a change along the lines described in (1) or (2) above happening at the same time. 4. I think this is a quite valuable proposal to have made. Thanks for that. Thanks and hope that helps, Jonathan