Message ID | 20221014142454.871196-2-carlos.bilbao@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp218586wrs; Fri, 14 Oct 2022 07:41:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5amamLYqWQV/kn5T8CrpW3ZEF2kBz6rZn5QiYgpeFlDo08DGWsu7s/q1xPL09mrNnnpUyc X-Received: by 2002:a05:6402:2926:b0:459:675b:38a9 with SMTP id ee38-20020a056402292600b00459675b38a9mr4549680edb.60.1665758504814; Fri, 14 Oct 2022 07:41:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1665758504; cv=pass; d=google.com; s=arc-20160816; b=CSSMKefb8dGQ7ic9wkzbNR0GSRrRaYaVxwNObwQVYkIagmiKpYGSam/1Zcs7hqjUM0 /mEO4tUwDFUNHZqOf2Jr44hp09UvrpmaWDySC+H3zqvLg68v5pFZ2yXhUpOEsNiUXzZ7 DL7JfCxxGm10SpPJTv/YgDlP1JlMr+e3WguILSCK5NaoyCWkw6SJZuHEbcozIU9ZhxpB tfeqwGI3PXqP4iHHTH5OFMYrJ6l3cc6i8g7gQ0vcaoFs9ctknbHQOYsgdA+As+HuCiEH wHOzUCg4oJHYHXvBbS/EL6ptL8WC1aTPFTrfKr/B4w+qx0X+0/IdrhoTwwCLSdYqd2hE C0Yw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ucfijwcKL18SJLYrpJXgCzV/+yPD1G4mZkaIyT9Dq3M=; b=xIskuMaLEOhe8h5qO/CjNYwZulzVuty1sgOa2dA1mONi0ORhbdlCe+Yyz/KBtn4zHd Rlf0gtGaU/V6yoPvbXZYkKZF2cNzZpyGmfnnUpGOkGnwFvynbnwUr4JDTBv2CrGJqaSB x178qJU4nPP8n6tszXSCc1cbZbnXd4Aw1e5gvY53L7lRzmckb1JnSffGJpggdDuBx4o7 IleEu6qvIQoLi4WL9gxPjZ/j3ZNBvepu3DpeLSFJ3TaQ4nvEn01rlzU8uJYa0LZo/m5h 37SMqQ5+cWVgMZC0aVxsaLHSnVXAolstcpShowOzdl5OuQPV+FMiUTqjUrLuEVAnNQAh XEsA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=TSqA++iM; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ds3-20020a170907724300b007307fd1b9bbsi2247964ejc.589.2022.10.14.07.41.17; Fri, 14 Oct 2022 07:41:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=TSqA++iM; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230194AbiJNOZJ (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Fri, 14 Oct 2022 10:25:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbiJNOZB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Oct 2022 10:25:01 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2084.outbound.protection.outlook.com [40.107.237.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D6F6248C3; Fri, 14 Oct 2022 07:24:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FO4d+svlkypMegKhzoMKdyRkPENZlnbR2ObttVj6frLFnqNBDn1IqVhSwnQzGdR1zQxxWZR2smAOQ8pkQWo/2LUrp2Zjr8tg3OQCqSNKEgJDqUB/LUy8yIqHuld5vmuFZ6H48kLLOZzJ0UwvXr8NtfcW84nA4yZ4RtK7ipOPC9uomqtayef6TRdS7myyLvclJ6UsGh/g8Ueu0+N8tI6JGBVxH5JtEkeTYFAc0rFfldzgWvJy9KUc/h/ZVNILwC9/1cNKR12p7K1ZWLEGq+tOHjB8CeL/cJJvEtLxfqDGcks+QtIf2YI7seWlnOmmCCjiqNr24rICjXVGunnf3MxqeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ucfijwcKL18SJLYrpJXgCzV/+yPD1G4mZkaIyT9Dq3M=; b=iuQnWTF6orWWSye6/FslV3N4G65U3u4bFLEaDLCDxEU/SrmtBJ0CLlRSJzbMfu9iMEhO535NFzP6fFG9X3aMpQ5I9/ApXm/KJROrr82bVQbrdHHnPfBxyVGNhm51FYqNAsrBgydEgchrxYH/I5oC4pYtNoO+75Kk+yccNk2fymp9mMjn08YIMtaYFJMM8NIr6kKNe6fzoh4uNPP8Uge19M/q3RO+sF2yEaBmcBGlaXivWwNgwOUxmPW49PsMlNgT9o3zm0Bhvs8058ABXVd98xxfjP+WyuSpZ7Tv25KeGkwXz7e5NIdekrC3XmwK3krbNAz27N561KSbADFMY4I5Xg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ucfijwcKL18SJLYrpJXgCzV/+yPD1G4mZkaIyT9Dq3M=; b=TSqA++iMAB2mVYwsMB8yn3lliIOb6YzwQjK/JLiR+6M2mNmWBbjEX+q7AyM6EQ67Kg5Qrh/9O6rREiFvnXP31u8I9Nwnf1XKr1EZkrkavN5Jm78NarlqCqPQLLQ7P+QSzvghyD3ZG+tjpYUmhgICOZYTXdu+uxz2047BQt60jIA= Received: from DS7PR03CA0233.namprd03.prod.outlook.com (2603:10b6:5:3ba::28) by BN9PR12MB5381.namprd12.prod.outlook.com (2603:10b6:408:102::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.26; Fri, 14 Oct 2022 14:24:57 +0000 Received: from DM6NAM11FT009.eop-nam11.prod.protection.outlook.com (2603:10b6:5:3ba:cafe::a2) by DS7PR03CA0233.outlook.office365.com (2603:10b6:5:3ba::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.30 via Frontend Transport; Fri, 14 Oct 2022 14:24:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT009.mail.protection.outlook.com (10.13.173.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5723.20 via Frontend Transport; Fri, 14 Oct 2022 14:24:56 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Fri, 14 Oct 2022 09:24:55 -0500 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Fri, 14 Oct 2022 09:24:55 -0500 Received: from iron-maiden.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2375.28 via Frontend Transport; Fri, 14 Oct 2022 09:24:55 -0500 From: Carlos Bilbao <carlos.bilbao@amd.com> To: <corbet@lwn.net> CC: <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <bilbao@vt.edu>, Carlos Bilbao <carlos.bilbao@amd.com> Subject: [PATCH v2 1/2] Documentation: Start translations to Spanish Date: Fri, 14 Oct 2022 09:24:53 -0500 Message-ID: <20221014142454.871196-2-carlos.bilbao@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221014142454.871196-1-carlos.bilbao@amd.com> References: <20221013184816.354278-1-carlos.bilbao@amd.com> <20221014142454.871196-1-carlos.bilbao@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT009:EE_|BN9PR12MB5381:EE_ X-MS-Office365-Filtering-Correlation-Id: 85628c3f-ffd1-407b-77d6-08daadefde32 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ueSa47appqZqQ6DuBXXIUYZzi9FRByJkDzyhMf0tR8cOlA0bvl026iYUY5dK3WYzLb/sG6QOPvPw6UbULJ+Otp5Wqt7WR9OCgMgVXsE7YIBTEVDHUyOu1Fc18U0R+c5Q6H+cVtB4UeQyL3o0vpD9sAzUGZ/blsYQnHT9PTsXZIOT8C59zhGaWtFB/qw6qilyHzOJ5WIHnjVZOSElHsjzXCc21u+8M3k0jPfb0tqz4uCLwnT3SNaNoWPBmSILGWjbw0haFyiuIpQZ/iY3asfCvuOqsXqXrvpOvc870srNrRozlJLHW3lIv/b+5/rblr4mfkHKg6L1Jxj9QXNGp+T5oeWDpn8CpWvTspsDUKEgiElm9g5IuY+b43FJgWxLL9tG9GPYvqUAf3j9YJGUWY7aH+CP/BbEliU+52R0/YFnQqU8Mx6pdKS/d3iHAHyoLTQ4YgDmA0ff64/X5rWOFu6grGdV9qFBA4MHlIVoF17Xo881g4tHs94I8qA6BEreKdkpiK7/ed0oEcgJyWnWOJi173qqSH3pSTCLlRMGs51TuG+UA/LAUsu7krKbp949S2dYlgcqaiF/1zTQCYIeQXvFqtKsWzj28cCwSQv6tvYpXpa5ir5udSzdF4oLF15iVFDtUkz/MWnIDB69Juy2lVz+QArXlrtRKYRxhtCfzj8js4mssXp6Kzs9Uc73nt6idUseFthJUWC2Eu2TeXCrRmEFv7CyKSKvGveYOraZQh4y6Dh731hQVfJhi/hzdM2V3g6TiGaDF7CgyMrOXcVUYxHnwSvRIKhAbP9ShePer2bgV7F51A/7EFwIlq2YJzs8vSdTXDZekbn4TQVh2mgfGXkMTA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230022)(4636009)(396003)(376002)(39860400002)(136003)(346002)(451199015)(40470700004)(36840700001)(46966006)(36756003)(70586007)(44832011)(426003)(86362001)(66574015)(2906002)(5660300002)(82310400005)(36860700001)(336012)(82740400003)(1076003)(186003)(47076005)(2616005)(81166007)(83380400001)(356005)(7696005)(478600001)(966005)(54906003)(6916009)(26005)(4326008)(8936002)(41300700001)(8676002)(40480700001)(70206006)(40460700003)(316002)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2022 14:24:56.2359 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85628c3f-ffd1-407b-77d6-08daadefde32 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT009.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5381 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746600087119925310?= X-GMAIL-MSGID: =?utf-8?q?1746674389569547892?= |
Series |
Documentation: Start Spanish translation and include HOWTO
|
|
Commit Message
Carlos Bilbao
Oct. 14, 2022, 2:24 p.m. UTC
Start the process of translating kernel documentation to Spanish. Create
sp_SP/ and include an index and a disclaimer, following the approach of
prior translations. Add Carlos Bilbao as MAINTAINER of this translation
effort.
Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
---
Documentation/translations/index.rst | 1 +
.../translations/sp_SP/disclaimer-sp.rst | 6 ++
Documentation/translations/sp_SP/index.rst | 72 +++++++++++++++++++
MAINTAINERS | 5 ++
4 files changed, 84 insertions(+)
create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
create mode 100644 Documentation/translations/sp_SP/index.rst
Comments
Hi Carlos, Since you Cc'd me, I guess I can give a quick review. :) On Fri, Oct 14, 2022 at 4:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote: > > +======================= > +Traducción al español > +======================= I think these should be as long as the title. > +La propagación simultanea de la traducción de una modificación en "simultánea" > +esté actualizada con las ultimas modificaciones. Si lo que lee en una "últimas" > +Una traducción no es una * bifurcación * de la documentación oficial, por I am not sure if the spaces are needed. > +ejemplo, nuevas traducciones, actualizaciones, correcciones). "...", "etc." or "o"/"y" before "correcciones"? > +Las traducciones tratan de ser lo más precisas posible pero no es posible > +convertir directamente un idioma a otro. Cada idioma tiene su propia > +gramática, y una cultura tras ella, por lo tanto, la traducción de una > +oración al inglés se podría modificar para adaptarlo al español. Por esta "adaptarla"? (if you are referring to "la traducción" or "una oración") > +la forma, pero todavía transmiten el mensaje original. A pesar de la gran > +difusión del inglés en el idioma hablado, cuando sea posible, expresiones > +en inglés serán reemplazadas por las palabras correspondientes en español. I think the sentence wants to say it is common (in the community?) to use English, but terms will be translated where possible. However, I am not sure what "en el idioma hablado" means here. Also, was this based on the English version or another translation? i.e. this sentence does not seem to be in the English one. > +sientan mas cómodos. En principio, estas pequeñas diferencias no deberían "más" > +La documentación del kernel de Linux > +==================================== I think without the last "de" would be more precise, but I have heard it this way too. > +bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de > +linux-doc en vger.kernel.org. Ditto. Cheers, Miguel
On 10/14/22 10:21, Miguel Ojeda wrote: > Hi Carlos, > > Since you Cc'd me, I guess I can give a quick review. :) Thanks Miguel. You came to mind immediately when thinking about CCing someone else that's a native speaker. > > On Fri, Oct 14, 2022 at 4:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote: >> +======================= >> +Traducción al español >> +======================= > I think these should be as long as the title. > >> +La propagación simultanea de la traducción de una modificación en > "simultánea" > >> +esté actualizada con las ultimas modificaciones. Si lo que lee en una > "últimas" > >> +Una traducción no es una * bifurcación * de la documentación oficial, por > I am not sure if the spaces are needed. > >> +ejemplo, nuevas traducciones, actualizaciones, correcciones). > "...", "etc." or "o"/"y" before "correcciones"? > >> +Las traducciones tratan de ser lo más precisas posible pero no es posible >> +convertir directamente un idioma a otro. Cada idioma tiene su propia >> +gramática, y una cultura tras ella, por lo tanto, la traducción de una >> +oración al inglés se podría modificar para adaptarlo al español. Por esta > "adaptarla"? (if you are referring to "la traducción" or "una oración") > >> +la forma, pero todavía transmiten el mensaje original. A pesar de la gran >> +difusión del inglés en el idioma hablado, cuando sea posible, expresiones >> +en inglés serán reemplazadas por las palabras correspondientes en español. > I think the sentence wants to say it is common (in the community?) to > use English, but terms will be translated where possible. However, I > am not sure what "en el idioma hablado" means here. > > Also, was this based on the English version or another translation? > i.e. this sentence does not seem to be in the English one. Yep, I took this from the Italian translation. They added: "Nonostante la grande diffusione di inglesismi nella lingua parlata, quando possibile, questi verranno sostituiti dalle corrispettive parole italiane" which in English is (more less): "Despite the popularity of English language in our field, use the corresponding term in Italian when possible." I believe the idea is that, even though we inherited English terms, like "bug", we should try to translate as much as possible and don't fall into what people sometimes refer to "Spanenglish", mixing both languages. > >> +sientan mas cómodos. En principio, estas pequeñas diferencias no deberían > "más" > >> +La documentación del kernel de Linux >> +==================================== > I think without the last "de" would be more precise, but I have heard > it this way too. > >> +bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de >> +linux-doc en vger.kernel.org. > Ditto. Thanks for your feedback, Miguel. I will wait to see if John has anything to add before I share updated patches. > > Cheers, > Miguel Best regards, Carlos
Carlos Bilbao <carlos.bilbao@amd.com> writes: > Thanks for your feedback, Miguel. I will wait to see if John has anything > to add before I share updated patches. I am, alas, not well qualified to judge a Spanish translation (leggo facilmente quello italiano, invece :), so I don't have anything to add there. There's no hurry in any case, I'll not apply this before the merge window closes. Thanks, jon
On 10/14/22 10:36, Jonathan Corbet wrote: > Carlos Bilbao <carlos.bilbao@amd.com> writes: > >> Thanks for your feedback, Miguel. I will wait to see if John has anything >> to add before I share updated patches. > I am, alas, not well qualified to judge a Spanish translation (leggo > facilmente quello italiano, invece :), so I don't have anything to add > there. > > There's no hurry in any case, I'll not apply this before the merge > window closes. Sounds good! In that case, I will wait a week to resend, to also give time for more potential feedback. > > Thanks, > > jon Thanks, Carlos
On Fri, Oct 14, 2022 at 5:33 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote: > > Thanks Miguel. You came to mind immediately when thinking about CCing > someone else that's a native speaker. My pleasure! > I believe the idea is that, even though we inherited English terms, like > "bug", we should try to translate as much as possible and don't fall into > what people sometimes refer to "Spanenglish", mixing both languages. Yeah, that was what I was thinking. Personally, I think translating common words like "bug" is fine, but more technical ones like "spinlock" may make things harder later when the reader goes into the source code or English docs. Thanks! I forgot, by the way: with the typos I mentioned fixed, it looks fine to me: Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Cheers, Miguel
Hi, Minor nit on language code. On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote: > Start the process of translating kernel documentation to Spanish. Create > sp_SP/ and include an index and a disclaimer, following the approach of > prior translations. Add Carlos Bilbao as MAINTAINER of this translation > effort. IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is listed at e.g., http://www.lingoes.net/en/translator/langcode.htm. The other translations use directory names found in the table, with "-" replaced with "_". It would be better to be consistent. Just my two cents. Thanks, Akira > > Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com> > --- > Documentation/translations/index.rst | 1 + > .../translations/sp_SP/disclaimer-sp.rst | 6 ++ > Documentation/translations/sp_SP/index.rst | 72 +++++++++++++++++++ > MAINTAINERS | 5 ++ > 4 files changed, 84 insertions(+) > create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst > create mode 100644 Documentation/translations/sp_SP/index.rst > > diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst > index 1175a47d07f0..b826c34791c0 100644 > --- a/Documentation/translations/index.rst > +++ b/Documentation/translations/index.rst > @@ -12,6 +12,7 @@ Translations > it_IT/index > ko_KR/index > ja_JP/index > + sp_SP/index > >
On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote: > Hi, > Minor nit on language code. > > On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote: > > Start the process of translating kernel documentation to Spanish. Create > > sp_SP/ and include an index and a disclaimer, following the approach of > > prior translations. Add Carlos Bilbao as MAINTAINER of this translation > > effort. > IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is > listed at e.g., http://www.lingoes.net/en/translator/langcode.htm. > > The other translations use directory names found in the table, with > "-" replaced with "_". It would be better to be consistent. I don't know what standard we're actually following. RFC5646 suggests simply using "es", with "es-419" for Latin America specialisation or "es-ES" for Spain. I don't know how much variation there is between different Spanish dialects for technical documents; as I understand it, it's worth supporting two dialects of Chinese, but we merrily mix & match en_US and en_GB spellings. Similarly, I wouldn't suggest that we have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr' would be fine. We do need to be careful here; people are rightfully sensitive about being incorrectly grouped together. If possible we should find a standard to follow that's been defined by experts in these matters. https://en.wikipedia.org/wiki/IETF_language_tag may be a good place to start looking.
On 2022/10/17 23:41, Matthew Wilcox wrote: > On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote: >> Hi, >> Minor nit on language code. >> >> On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote: >>> Start the process of translating kernel documentation to Spanish. Create >>> sp_SP/ and include an index and a disclaimer, following the approach of >>> prior translations. Add Carlos Bilbao as MAINTAINER of this translation >>> effort. >> IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is >> listed at e.g., http://www.lingoes.net/en/translator/langcode.htm. >> >> The other translations use directory names found in the table, with >> "-" replaced with "_". It would be better to be consistent. > > I don't know what standard we're actually following. RFC5646 suggests > simply using "es", with "es-419" for Latin America specialisation or > "es-ES" for Spain. I don't know how much variation there is between > different Spanish dialects for technical documents; as I understand it, > it's worth supporting two dialects of Chinese, but we merrily mix & > match en_US and en_GB spellings. Similarly, I wouldn't suggest that we > have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr' > would be fine. > > We do need to be careful here; people are rightfully sensitive about > being incorrectly grouped together. If possible we should find a > standard to follow that's been defined by experts in these matters. > https://en.wikipedia.org/wiki/IETF_language_tag may be a good place to > start looking. I think generic "es" is OK, especially if "es_ES" can have such a negative connotation to some. I just wanted to point out "sp_SP" looks wrong. Carlos, if you go the "es" way, it would be better to mention the reason of the choice in the Changelog for future reference. Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under Documentation/ way back in 2007 (v2.6.23). As you might see, two of the three language codes needed region distinction and they were reasonable choices at the time. Thanks, Akira
On 10/17/22 21:36, Akira Yokosawa wrote: > On 2022/10/17 23:41, Matthew Wilcox wrote: >> On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote: >>> Hi, >>> Minor nit on language code. >>> >>> On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote: >>>> Start the process of translating kernel documentation to Spanish. Create >>>> sp_SP/ and include an index and a disclaimer, following the approach of >>>> prior translations. Add Carlos Bilbao as MAINTAINER of this translation >>>> effort. >>> IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is >>> listed at e.g., https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lingoes.net%2Fen%2Ftranslator%2Flangcode.htm&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bTm9yjEtum2LkTFkN1kZphytfVKN9Si2Ypk7j6s%2FaVw%3D&reserved=0. >>> >>> The other translations use directory names found in the table, with >>> "-" replaced with "_". It would be better to be consistent. >> I don't know what standard we're actually following. RFC5646 suggests >> simply using "es", with "es-419" for Latin America specialisation or >> "es-ES" for Spain. I don't know how much variation there is between >> different Spanish dialects for technical documents; as I understand it, >> it's worth supporting two dialects of Chinese, but we merrily mix & >> match en_US and en_GB spellings. Similarly, I wouldn't suggest that we >> have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr' >> would be fine. >> >> We do need to be careful here; people are rightfully sensitive about >> being incorrectly grouped together. If possible we should find a >> standard to follow that's been defined by experts in these matters. >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIETF_language_tag&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3T9bPQzcj9hEuZiPkjIU%2BPCEaxAivgaNKZ2gL5m3OQA%3D&reserved=0 may be a good place to >> start looking. > I think generic "es" is OK, especially if "es_ES" can have such a > negative connotation to some. I just wanted to point out "sp_SP" > looks wrong. > > Carlos, if you go the "es" way, it would be better to mention the > reason of the choice in the Changelog for future reference. > > Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under > Documentation/ way back in 2007 (v2.6.23). > > As you might see, two of the three language codes needed region > distinction and they were reasonable choices at the time. > > Thanks, Akira Answering to Akira and Matthew below. Thanks to both for valuable feedback. I made the conscious choice of not using es_ES, because as mentioned, it references a standard that I don’t intend to follow myself or enforce on Spanish translations. es_ES is a standard that comes from “Esp”-aña (Spain, the country) whereas “sp_SP” is as in "Sp"-anish, the language, not the country. Regarding this, I took the liberty of adding an extra paragraph to index.rs. I would translate it to English like: "Many countries speak Spanish, each one with its own culture, expressions, and sometimes significant grammatical differences. The translators are free to use the version of Spanish which they are most comfortable with. In principle, these small differences should not pose a great barrier for speakers of different versions of Spanish, albeit in case of doubt, you can ask the maintainers." I also opted for not using es_ES due to its geographical connotations. If someone from Peru, Mexico, Argentina, … submits a translation tomorrow, I would review it and we would understand each other just fine. Even within “Spain” there are many dialects and things change within regions. I reiterate that all dialects should be allowed in this directory. Fortunately for us, versions of Spanish differ much more in spoken form than they do when written. This does not happen between traditional and simplified Chinese. On top of everything else, using locale es_ES may imply that spell checks on that directory using the locale es_ES would be clean, but this is very far from reality, among other things, because all the English terms we inherit regarding computers. As Miguel Ojeda pointed out somewhere in this thread, there are terms that is better if we do not translate, to favor understanding of code/other documents. I will update the corresponding commit message to clarify why we are using es_ES format in this particular case. Best regards, Carlos
On Mon, Oct 24, 2022 at 08:40:42AM -0500, Carlos Bilbao wrote: > > > I don't know what standard we're actually following. RFC5646 suggests > > > simply using "es", with "es-419" for Latin America specialisation or > > > "es-ES" for Spain. I don't know how much variation there is between > > > different Spanish dialects for technical documents; as I understand it, > > > it's worth supporting two dialects of Chinese, but we merrily mix & > > > match en_US and en_GB spellings. Similarly, I wouldn't suggest that we > > > have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr' > > > would be fine. > > > > > > We do need to be careful here; people are rightfully sensitive about > > > being incorrectly grouped together. If possible we should find a > > > standard to follow that's been defined by experts in these matters. > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIETF_language_tag&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3T9bPQzcj9hEuZiPkjIU%2BPCEaxAivgaNKZ2gL5m3OQA%3D&reserved=0 may be a good place to > > > start looking. > > I think generic "es" is OK, especially if "es_ES" can have such a > > negative connotation to some. I just wanted to point out "sp_SP" > > looks wrong. > > > > Carlos, if you go the "es" way, it would be better to mention the > > reason of the choice in the Changelog for future reference. > > > > Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under > > Documentation/ way back in 2007 (v2.6.23). > > > > As you might see, two of the three language codes needed region > > distinction and they were reasonable choices at the time. > > > > Thanks, Akira > > Answering to Akira and Matthew below. Thanks to both for valuable feedback. > > I made the conscious choice of not using es_ES, because as mentioned, it > references a standard that I don’t intend to follow myself or enforce on > Spanish translations. es_ES is a standard that comes from “Esp”-aña (Spain, > the country) whereas “sp_SP” is as in "Sp"-anish, the language, not the > country. Regarding this, I took the liberty of adding an extra paragraph to > index.rs. I would translate it to English like: > > "Many countries speak Spanish, each one with its own culture, expressions, > and sometimes significant grammatical differences. The translators are free > to use the version of Spanish which they are most comfortable with. In > principle, these small differences should not pose a great barrier for > speakers of different versions of Spanish, albeit in case of doubt, you can > ask the maintainers." > > I also opted for not using es_ES due to its geographical connotations. If > someone from Peru, Mexico, Argentina, … submits a translation tomorrow, I > would review it and we would understand each other just fine. Even within > “Spain” there are many dialects and things change within regions. I > reiterate that all dialects should be allowed in this directory. > > Fortunately for us, versions of Spanish differ much more in spoken form > than they do when written. This does not happen between traditional and > simplified Chinese. > > On top of everything else, using locale es_ES may imply that spell checks > on that directory using the locale es_ES would be clean, but this is very > far from reality, among other things, because all the English terms we > inherit regarding computers. As Miguel Ojeda pointed out somewhere in this > thread, there are terms that is better if we do not translate, to favor > understanding of code/other documents. > > I will update the corresponding commit message to clarify why we are using > es_ES format in this particular case. I think we're better off following BCP 47: https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. That will imply renaming it_IT to simply "it", ja_JP to "ja" and ko_KR to "ko". The two Chinese translations we have might be called "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs Simplified script. If they really are region based, then they'd be zh-CN and zh-TW. I think you're right to conflate all dialects of Spanish together, just as we do all dialects of English. Jon, this feels like policy you should be setting. Are you on board with this, or do you want to retain the mandatory geography tag that we've been using up to now?
On Mon, Oct 24, 2022 at 3:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote: > > Fortunately for us, versions of Spanish differ much more in spoken form > than they do when written. Agreed: in Spanish, the differences, in particular in formal/technical texts, are very minor. Cheers, Miguel
[Adding some of the other folks interested in translations] Matthew Wilcox <willy@infradead.org> writes: > I think we're better off following BCP 47: > https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. > That will imply renaming it_IT to simply "it", ja_JP to "ja" and > ko_KR to "ko". The two Chinese translations we have might be called > "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs > Simplified script. If they really are region based, then they'd be > zh-CN and zh-TW. > > I think you're right to conflate all dialects of Spanish together, just > as we do all dialects of English. > > Jon, this feels like policy you should be setting. Are you on board > with this, or do you want to retain the mandatory geography tag that > we've been using up to now? I want to go hide somewhere :) I'd kind of prefer to avoid renaming the existing translations, as that is sure to create a certain amount of short-term pain. But I guess we could do that if the benefit somehow seems worth it. Of course, if we're thrashing things, we could also just call them "Italian" (or "Italiano"), "Chinese", and so on. I don't *think* there's a need for the names to be machine-readable. We should stick with ASCII for these names just to help those of us who can't type in other scripts. If asked to set a policy today, my kneejerk reaction would be to leave things as they are just to avoid a bunch of churn. But I don't have a strong opinion on how this naming should actually be done, as long as we can pick something and be happy with it thereafter. What do the translation maintainers think? Thanks, jon
Resending without the screwy address that my mailer decided to put in for Alex, sorry for the noise. Jonathan Corbet <corbet@lwn.net> writes: > [Adding some of the other folks interested in translations] > > Matthew Wilcox <willy@infradead.org> writes: > >> I think we're better off following BCP 47: >> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. >> That will imply renaming it_IT to simply "it", ja_JP to "ja" and >> ko_KR to "ko". The two Chinese translations we have might be called >> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs >> Simplified script. If they really are region based, then they'd be >> zh-CN and zh-TW. >> >> I think you're right to conflate all dialects of Spanish together, just >> as we do all dialects of English. >> >> Jon, this feels like policy you should be setting. Are you on board >> with this, or do you want to retain the mandatory geography tag that >> we've been using up to now? > > I want to go hide somewhere :) > > I'd kind of prefer to avoid renaming the existing translations, as that > is sure to create a certain amount of short-term pain. But I guess we > could do that if the benefit somehow seems worth it. > > Of course, if we're thrashing things, we could also just call them > "Italian" (or "Italiano"), "Chinese", and so on. I don't *think* > there's a need for the names to be machine-readable. We should stick > with ASCII for these names just to help those of us who can't type in > other scripts. > > If asked to set a policy today, my kneejerk reaction would be to leave > things as they are just to avoid a bunch of churn. But I don't have a > strong opinion on how this naming should actually be done, as long as we > can pick something and be happy with it thereafter. What do the > translation maintainers think? > > Thanks, > > jon
On 10/24/22 10:31, Jonathan Corbet wrote: > Resending without the screwy address that my mailer decided to put in > for Alex, sorry for the noise. > > Jonathan Corbet <corbet@lwn.net> writes: > >> [Adding some of the other folks interested in translations] >> >> Matthew Wilcox <willy@infradead.org> writes: >> >>> I think we're better off following BCP 47: >>> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. >>> That will imply renaming it_IT to simply "it", ja_JP to "ja" and >>> ko_KR to "ko". The two Chinese translations we have might be called >>> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs >>> Simplified script. If they really are region based, then they'd be >>> zh-CN and zh-TW. >>> >>> I think you're right to conflate all dialects of Spanish together, just >>> as we do all dialects of English. >>> >>> Jon, this feels like policy you should be setting. Are you on board >>> with this, or do you want to retain the mandatory geography tag that >>> we've been using up to now? >> I want to go hide somewhere :) >> >> I'd kind of prefer to avoid renaming the existing translations, as that >> is sure to create a certain amount of short-term pain. But I guess we >> could do that if the benefit somehow seems worth it. >> >> Of course, if we're thrashing things, we could also just call them >> "Italian" (or "Italiano"), "Chinese", and so on. I don't *think* >> there's a need for the names to be machine-readable. We should stick >> with ASCII for these names just to help those of us who can't type in >> other scripts. >> >> If asked to set a policy today, my kneejerk reaction would be to leave >> things as they are just to avoid a bunch of churn. But I don't have a >> strong opinion on how this naming should actually be done, as long as we >> can pick something and be happy with it thereafter. What do the >> translation maintainers think? >> >> Thanks, >> >> jon From the perspective of the target audience (someone that wants to read translated documentation) the name of the directories do not make any difference; index.rst lists them in human readable format (e.g. "Traduzione italiana"). It would make sense renaming if there was confusion among developers, but there isn't. For these reasons, and for the obvious inconvenience of renaming things back and forth, I would say do not worry about it, Jon. Thanks, Carlos
On Mon, Oct 24, 2022 at 11:31 PM Jonathan Corbet <corbet@lwn.net> wrote: > > > Resending without the screwy address that my mailer decided to put in > for Alex, sorry for the noise. Thanks for having me. I am neutral about the change, and prefer less churn for code. But if we have to, zh_hant/hans is better then CN and TW to comfort other regions, like zh_SG, zh_HK etc. Thanks Alex > > Jonathan Corbet <corbet@lwn.net> writes: > > > [Adding some of the other folks interested in translations] > > > > Matthew Wilcox <willy@infradead.org> writes: > > > >> I think we're better off following BCP 47: > >> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. > >> That will imply renaming it_IT to simply "it", ja_JP to "ja" and > >> ko_KR to "ko". The two Chinese translations we have might be called > >> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs > >> Simplified script. If they really are region based, then they'd be > >> zh-CN and zh-TW. > >> > >> I think you're right to conflate all dialects of Spanish together, just > >> as we do all dialects of English. > >> > >> Jon, this feels like policy you should be setting. Are you on board > >> with this, or do you want to retain the mandatory geography tag that > >> we've been using up to now? > > > > I want to go hide somewhere :) > > > > I'd kind of prefer to avoid renaming the existing translations, as that > > is sure to create a certain amount of short-term pain. But I guess we > > could do that if the benefit somehow seems worth it. > > > > Of course, if we're thrashing things, we could also just call them > > "Italian" (or "Italiano"), "Chinese", and so on. I don't *think* > > there's a need for the names to be machine-readable. We should stick > > with ASCII for these names just to help those of us who can't type in > > other scripts. > > > > If asked to set a policy today, my kneejerk reaction would be to leave > > things as they are just to avoid a bunch of churn. But I don't have a > > strong opinion on how this naming should actually be done, as long as we > > can pick something and be happy with it thereafter. What do the > > translation maintainers think? > > > > Thanks, > > > > jon
在 2022/10/25 19:05, Alex Shi 写道: > On Mon, Oct 24, 2022 at 11:31 PM Jonathan Corbet <corbet@lwn.net> wrote: >> >> Resending without the screwy address that my mailer decided to put in >> for Alex, sorry for the noise. > Thanks for having me. > I am neutral about the change, and prefer less churn for code. > But if we have to, zh_hant/hans is better then CN and TW to comfort > other regions, like zh_SG, zh_HK etc. Same here! >_< Thanks, Yanteng > > Thanks > Alex > >> Jonathan Corbet <corbet@lwn.net> writes: >> >>> [Adding some of the other folks interested in translations] >>> >>> Matthew Wilcox <willy@infradead.org> writes: >>> >>>> I think we're better off following BCP 47: >>>> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format. >>>> That will imply renaming it_IT to simply "it", ja_JP to "ja" and >>>> ko_KR to "ko". The two Chinese translations we have might be called >>>> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs >>>> Simplified script. If they really are region based, then they'd be >>>> zh-CN and zh-TW. >>>> >>>> I think you're right to conflate all dialects of Spanish together, just >>>> as we do all dialects of English. >>>> >>>> Jon, this feels like policy you should be setting. Are you on board >>>> with this, or do you want to retain the mandatory geography tag that >>>> we've been using up to now? >>> I want to go hide somewhere :) >>> >>> I'd kind of prefer to avoid renaming the existing translations, as that >>> is sure to create a certain amount of short-term pain. But I guess we >>> could do that if the benefit somehow seems worth it. >>> >>> Of course, if we're thrashing things, we could also just call them >>> "Italian" (or "Italiano"), "Chinese", and so on. I don't *think* >>> there's a need for the names to be machine-readable. We should stick >>> with ASCII for these names just to help those of us who can't type in >>> other scripts. >>> >>> If asked to set a policy today, my kneejerk reaction would be to leave >>> things as they are just to avoid a bunch of churn. But I don't have a >>> strong opinion on how this naming should actually be done, as long as we >>> can pick something and be happy with it thereafter. What do the >>> translation maintainers think? >>> >>> Thanks, >>> >>> jon
diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst index 1175a47d07f0..b826c34791c0 100644 --- a/Documentation/translations/index.rst +++ b/Documentation/translations/index.rst @@ -12,6 +12,7 @@ Translations it_IT/index ko_KR/index ja_JP/index + sp_SP/index .. _translations_disclaimer: diff --git a/Documentation/translations/sp_SP/disclaimer-sp.rst b/Documentation/translations/sp_SP/disclaimer-sp.rst new file mode 100644 index 000000000000..a400034e95f9 --- /dev/null +++ b/Documentation/translations/sp_SP/disclaimer-sp.rst @@ -0,0 +1,6 @@ +:orphan: + +.. warning:: + Si tiene alguna duda sobre la exactitud del contenido de esta + traducción, la única referencia válida es la documentación oficial en + inglés. diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst new file mode 100644 index 000000000000..2800041168f4 --- /dev/null +++ b/Documentation/translations/sp_SP/index.rst @@ -0,0 +1,72 @@ +.. _sp_linux_doc: + +======================= +Traducción al español +======================= + +.. raw:: latex + + \kerneldocCJKoff + +:maintainer: Carlos Bilbao <carlos.bilbao@amd.com> + +.. _sp_disclaimer: + +Advertencia +=========== + +El objetivo de esta traducción es facilitar la lectura y comprensión para +aquellos que no entiendan inglés o duden de sus interpretaciones, o +simplemente para aquellos que prefieran leer en el idioma español. Sin +embargo, tenga en cuenta que la *única* documentación oficial es la que +está en inglés: :ref:`linux_doc` + +La propagación simultanea de la traducción de una modificación en +:ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores +de la traducción intentan mantener sus traducciones al día, en tanto les +es posible. Por tanto, no existe ninguna garantía de que una traducción +esté actualizada con las ultimas modificaciones. Si lo que lee en una +traducción no se corresponde con lo que ve en el código fuente, informe +al maintainer de la traducción y, si puede, consulte la documentación en +inglés. + +Una traducción no es una * bifurcación * de la documentación oficial, por +lo que los usuarios no encontrarán aquí ninguna información que no sea la +versión oficial. Cualquier adición, supresión o modificación de los +contenidos deberá ser realizada anteriormente en los documentos en inglés. +Posteriormente, y cuando sea posible, dicho cambio debería aplicarse +también a las traducciones. Los maintainers de las traducciones aceptan +contribuciones que son puramente de interés relativo a la traducción (por +ejemplo, nuevas traducciones, actualizaciones, correcciones). + +Las traducciones tratan de ser lo más precisas posible pero no es posible +convertir directamente un idioma a otro. Cada idioma tiene su propia +gramática, y una cultura tras ella, por lo tanto, la traducción de una +oración al inglés se podría modificar para adaptarlo al español. Por esta +razón, cuando lea esta traducción, puede encontrar algunas diferencias en +la forma, pero todavía transmiten el mensaje original. A pesar de la gran +difusión del inglés en el idioma hablado, cuando sea posible, expresiones +en inglés serán reemplazadas por las palabras correspondientes en español. + +Si necesita ayuda para comunicarse con la comunidad de Linux pero no se +siente cómodo escribiendo en inglés, puede pedir ayuda al maintainer para +obtener una traducción. + +Muchos países hablan español, cada uno con su propia cultura, expresiones, +y diferencias gramaticales en ocasiones significativas. Las traducciones de +los maintainers pueden utilizar el español con el que dichos maintainers se +sientan mas cómodos. En principio, estas pequeñas diferencias no deberían +suponer una gran barrera para hablantes de distintas versiones del español, +pero en caso de duda se puede consultar a los maintainers. + +La documentación del kernel de Linux +==================================== + +Este es el nivel superior de la documentación del kernel en idioma español. +La traducción es incompleta, y podría encontrar advertencias que indiquen +la falta de una traducción o de un grupo de traducciones. + +En términos más generales, la documentación, como el kernel mismo, están en +constante desarrollo. Las mejoras en la documentación siempre son +bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de +linux-doc en vger.kernel.org. diff --git a/MAINTAINERS b/MAINTAINERS index 944dc265b64d..b3133f013efb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19150,6 +19150,11 @@ W: https://linuxtv.org Q: http://patchwork.linuxtv.org/project/linux-media/list/ F: drivers/media/dvb-frontends/sp2* +SPANISH DOCUMENTATION +M: Carlos Bilbao <carlos.bilbao@amd.com> +S: Maintained +F: Documentation/translations/sp_SP/ + SPARC + UltraSPARC (sparc/sparc64) M: "David S. Miller" <davem@davemloft.net> L: sparclinux@vger.kernel.org