> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > Kent Karlsson > > If they have Macrolanguage situation, > > They don't, almost by definition. See Peter's explanation > of why the notion of "macrolanguage" was invented. It had to > do with matching -2 codes with -3 codes. So far Võro has > not had a language code, so there is no such matching issue. I don't quite follow this. The origins of the macrolanguage notion arose in figuring out how to map items in 639-2 with the candidates for 639-3, but the definition of macrolanguage doesn't reference that. If et/est was only used for Standard Estonian, then it might be possible to say that Võro is simply something new. On the other hand, if there is existing usage of et/est for Võro, and if Võro and Std Estonian are considered distinct languages, then it would be the case that et/est is used (at least in some contexts) for distinct languages -- making it either a collection or macrolanguage. If there are some contexts in which et/estFrom ltru-bounces at ietf.org Tue Jun 3 18:22:19 2008 Return-Path: <ltru-bounces at ietf.org> X-Original-To: ltru-archive at megatron.ietf.org Delivered-To: ietfarch-ltru-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DF83A6A17; Tue, 3 Jun 2008 18:22:19 -0700 (PDT) X-Original-To: ltru at core3.amsl.com Delivered-To: ltru at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C62A3A6A17 for <ltru at core3.amsl.com>; Tue, 3 Jun 2008 18:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b10yDD+LDqIJ for <ltru at core3.amsl.com>; Tue, 3 Jun 2008 18:22:17 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 55BA53A6A05 for <ltru at ietf.org>; Tue, 3 Jun 2008 18:22:17 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 3 Jun 2008 18:22:20 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.18.48]) with mapi; Tue, 3 Jun 2008 18:22:20 -0700 From: Peter Constable <petercon at microsoft.com> To: 'LTRU Working Group' <ltru at ietf.org> Date: Tue, 3 Jun 2008 18:22:19 -0700 Thread-Topic: [Ltru] heads up: Estonian Thread-Index: AcjFpsuIymT690QgR7qNyxmWPJuulQACrJeAAAtppUAMessage-ID: <DDB6DE6E9D27DD478AE6D1BBBB8357956333680DA4 at NA-EXMSG-C117.redmond.corp.microsoft.com> References: <DDB6DE6E9D27DD478AE6D1BBBB8357956333544A09 at NA-EXMSG-C117.redmond.corp.microsoft.com><95616C5245684E28948A8BE9F1AFA7C1 at streamserve.com> <48458AEC.1030503 at malform.no> <E10B3E2B563C4ED7B0B9D9136CCDBDBC at streamserve.com> In-Reply-To: <E10B3E2B563C4ED7B0B9D9136CCDBDBC at streamserve.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ltru] heads up: Estonian X-BeenThere: ltru at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ltru> List-Post: <mailto:ltru at ietf.org> List-Help: <mailto:ltru-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request at ietf.org?subject=subscribe> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ltru-bounces at ietf.org Errors-To: ltru-bounces at ietf.org > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > Kent Karlsson > > If they have Macrolanguage situation, > > They don't, almost by definition. See Peter's explanation > of why the notion of "macrolanguage" was invented. It had to > do with matching -2 codes with -3 codes. So far Võro has > not had a language code, so there is no such matching issue. I don't quite follow this. The origins of the macrolanguage notion arose in figuring out how to map items in 639-2 with the candidates for 639-3, but the definition of macrolanguage doesn't reference that. If et/est was only used for Standard Estonian, then it might be possible to say that Võro is simply something new. On the other hand, if there is existing usage of et/est for Võro, and if Võro and Std Estonian are considered distinct languages, then it would be the case that et/est is used (at least in some contexts) for distinct languages -- making it either a collection or macrolanguage. If there are some contexts in which et/est is cons is considered to be a single language, then those options are reduced to macrolanguage. There are a bunch of "if"s in there. Your suggestion earlier is that we not consider et/est as encompassing Võro. There are, however, known instances of just that, however. At some point, we face a dilemma: either - we intentionally narrow denotations to ensure stability and freedom from problems for the majority language; or - we deprecate the existing category and create new categories for the split, giving us a set of categories free of the macrolanguage problems and stability in the denotation of existing IDs, but a situation in which a deprecated category is what many applications continue to use and consider preferred, and in which there's no formal connection between the old ID and the new ones; or - we re-scope the existing ID as macrolanguage and add new IDs for encompassed languages, ensuring stability in denotation of the existing ID but taking on potential issues that come with macrolanguages (we probably are hoping that the macrolanguage can continue to be used as in the past, with most actual usage being specifically for the predominant language, the rest not being of significance for most of our applications); or - we push back on requests to encode the encompassed varieties, possibly ignoring legitimate cases with valid needs. Peter _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru idered to be a single language, then those options are reduced to macrolanguage. There are a bunch of "if"s in there. Your suggestion earlier is that we not consider et/est as encompassing Võro. There are, however, known instances of just that, however. At some point, we face a dilemma: either - we intentionally narrow denotations to ensure stability and freedom from problems for the majority language; or - we deprecate the existing category and create new categories for the split, giving us a set of categories free of the macrolanguage problems and stability in the denotation of existing IDs, but a situation in which a deprecated category is what many applications continue to use and consider preferred, and in which there's no formal connection between the old ID and the new ones; or - we re-scope the existing ID as macrolanguage and add new IDs for encompassed languages, ensuring stability in denotation of the existing ID but taking on potential issues that come with macrolanguages (we probably are hoping that the macrolanguage can continue to be used as in the past, with most actual usage being specifically for the predominant language, the rest not being of significance for most of our applications); or - we push back on requests to encode the encompassed varieties, possibly ignoring legitimate cases with valid needs. Peter _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.