From owner-freebsd-doc@FreeBSD.ORG Mon Jul 10 13:47:57 2006 Return-Path: X-Original-To: FreeBSD-doc@FreeBSD.org Delivered-To: FreeBSD-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E164716A4DD; Mon, 10 Jul 2006 13:47:56 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (vlsi00.si.noda.tus.ac.jp [133.31.130.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A06B43D45; Mon, 10 Jul 2006 13:47:55 +0000 (GMT) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p6168-ipbf302funabasi.chiba.ocn.ne.jp [124.87.184.168]) (authenticated bits=128) by mail.allbsd.org (8.13.1/8.13.4) with ESMTP id k6ADlf9N031517; Mon, 10 Jul 2006 22:47:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id k6ADlQqm021841; Mon, 10 Jul 2006 22:47:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 10 Jul 2006 22:46:14 +0900 (JST) Message-Id: <20060710.224614.59482634.hrs@allbsd.org> To: chinsan.tw@gmail.com From: Hiroki Sato In-Reply-To: <1f27304c0607100524n19f54596n306c35228dad7d6a@mail.gmail.com> References: <1f27304c0607100524n19f54596n306c35228dad7d6a@mail.gmail.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 4.2.52 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Jul_10_22_46_14_2006_524)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on gatekeeper.allbsd.org X-Virus-Status: Clean Cc: FreeBSD-doc@FreeBSD.org, doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org Subject: Re: cvs commit: doc/zh_TW.Big5/books/zh-tut Makefile zh-tut.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 13:47:57 -0000 ----Security_Multipart(Mon_Jul_10_22_46_14_2006_524)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit chinsan wrote in <1f27304c0607100524n19f54596n306c35228dad7d6a@mail.gmail.com>: ch> However, The real problem in fact is we have to create some native,tutorial, ch> useful document, and these document must have "FDP-compliant" which ch> defined(by you) English must always first. No, I use "FDP-compliant" for directory structure of the document and so on. Whether there has to always be with the English counterpart or not is what I want to discuss here. ch> Or do you think to write in native language(ie. Japanese) is more difficult ch> than non-native language? ch> Please answer "yes" or "no." If "no," please list the differences ch> between native and non-native. I am still not sure what you are trying to mean. I think writing documents in the native language is easier for the author, but it is not a problem I raised. The point is that the original document in the tree is, regardless it is written in English or other languages, an "official" one. As I wrote in the previous mail, I think most of us are considering that the English documents are official and original, and we have a rough consensus on that the official language of our documentation set is English. For example, the latest release includes the English release documents only, and just before the doc tree is tagged updating English documents has our priority. All of them are based on the idea. Importing a non-English document without the English counterpart can break this supposition. This means that we must maintain original documents written in non-English languages. This is what I want to discuss here. I think it is too difficult to maintain original (official) documents written in various languages, and even if such importing is allowed we must have a guideline. Please imagine various documents in various languages inconsistently imported in the name of usefulness. No one can control the quality and the release engineering becomes quite difficult. I think we must consider the positive and the negative effects of it and reach a consensus now. I DO NOT insist that non-translation documents in non-English languages should be removed immediately. Also, my comments in this series of emails are not on behalf of doceng@, and I never request vanilla@ to remove zh-tut. Any comments are welcome. ch> Finally, as you said: "there is no common view about adding something other than ch> the translations into there (AFAIK)", can you explain why the ch> following document exist? ch> fr_FR.ISO8859-1/articles/ddwg ch> fr_FR.ISO8859-1/articles/ip-aliasing ch> fr_FR.ISO8859-1/articles/make-world ch> fr_FR.ISO8859-1/articles/ntfs ch> fr_FR.ISO8859-1/articles/ppp ch> it_IT.ISO8859-15/books/unix-introduction Yes, I said "there is no common view". These imports and zh-tut are done just because of it. So, I raise this as an issue. I took a cue from zh-tut actually, but I am not talking about zh-tut only. ch> If you feel that question's unfair, please give me your vision for ch> FDP's spirit, philosophy and all the game rules. ch> Make it clear and honest, without finessing or posturing. Again, I use the word FDP as the conventions such as directory layout and so on. They are not spiritual ones. -- | Hiroki SATO ----Security_Multipart(Mon_Jul_10_22_46_14_2006_524)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBEslooTyzT2CeTzy0RAucgAJ433rexWQ6uFK12SS3qwmYlua2rsQCgiEyf hIz59eCCX2btnnnV/neuHy0= =NSgO -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Jul_10_22_46_14_2006_524)----