Subject: [Ltru] Re: Alemanic & Swiss German

From: "Doug Ewell" <[email-masked]>
Date: Sat, 2 Dec 2006 00:09:31 -0800

Peter Constable <petercon at microsoft dot com> wrote:

> On the one hand, we see Ethnologue use “Alemannic” in reference to the 
> genetic subnode. On the other, we see Ethnologue indicate that 
> “Alemannisch” is a name used to refer to the specific language also 
> known as “Schwyzerdütsch” or “Swiss German”.

I don't know if this sheds light on anything, but there is a similar 
ambiguity in the English term "classical music."  It can be used to mean 
either (a) the entire genre of so-called "serious" music, as contrasted 
with "popular" styles such as folk or rock, or (b) such music from the 
"classical era," spanning roughly from the mid-18th to the early 19th 
centuries.  In one sense, Bach and Tchaikovsky were "classical" 
composers; in another sense they were not.

Usually context makes it clear which of these senses is intended.  It 
seems this would not be sufficient to disambiguate the name "Alemanic" 
in the Registry, however.  Perhaps this is one of those cases where a 
brief and judicious Comment could be added, to the effect (assuming 
Peter's interpretation is correct) that "gsw" refers to only one 
language and other "Alemannic" language could be tagged using 
such-and-so subtag.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: <[email-masked]>
Date: Sat, 2 Dec 2006 09:56:47 -0000

Whilst being new to the field and recently tied up on other things, or perhaps because I am new, I have been thinking of ways by which ISO/TC 37 terminology work principles and practices can be employed to deal with some of the purely terminological problems I have already come across in the exisiting or about to exist 639 codes with regard to naming.  The difficulty being to achieve that without upsetting the equally important need for stability in code elements already in widespread use (including the invaluable Ethnologue data and information about language families and groups).  
This theme started me thinking again and I believe a form of solution can be provided by having this in mind as a need to be addressed in the development of ISO 639-6 content. 
It does not of course affect the equally important issues currently being discussed of identifying precisely what the object is in the firsd place or allocating an identifier/code.
IMO problems in precision using language go back to Wittgenstein's final understanding that we work best fuzzy so the problems arise when fuzzy or even a fuzzy approach to the attempt to be precise is not good enough for purpose.
Chris
----- Original Message -----
From: Doug Ewell [mailto:[email-masked]]
To: [email-masked]
Sent: Sat, 2 Dec 2006 00:09:31 -0800
Subject: [Ltru] Re: Alemanic & Swiss German

Peter Constable <petercon at microsoft dot com> wrote:

> On the one hand, we see Ethnologue use ???Alemannic??? in reference to the 
> ???Alemannisch??? is a name used to refer to the specific language also 
> known as ???Schwyzerd??tsch??? or ???Swiss German???.

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru
Whilst being new to the field and recently tied up on other things, or perhaps because I am new, I have been thinking of ways by which ISO/TC 37 terminology work principles and practices can be employed to deal with some of the purely terminological problems I have already come across in the exisiting or about to exist 639 codes with regard to naming.  The difficulty being to achieve that without upsetting the equally important need for stability in code elements already in widespread use (including the invaluable Ethnologue data and information).  
This theme started me thinking again and I believe a form of solution can be provided by having this in mind as a need to be addressed in the development of ISO 639-6 content. 
It does not of course affect the equally important issues currently being discussed of identifying precisely what the object is in the firsd place or allocating an identifier/code.
IMO problems in precision using language go back to Wittgenstein's final understanding that we work best fuzzy so the problems arise when fuzzy or even a fuzzy approach to the attempt to be precise is not good enough for purpose.
Chris

---

From: [email-masked]
Date: Mon, 4 Dec 2006 18:53:27 -0800

So should "Allemanisch" be added to the name_in_vern parameter to make it 
clear that this dialect is included? 

Maybe this helps:

A brief search on the web indicates that Alemanic/Alemannic -- when used 
as a *noun* and not an adjective -- most commonly refers to the Austrian 
form of Swiss German. The name_in_eng category clearly references a noun 
and not an adjective. I believe the way Mark is using the term, he is 
referring to an adjective. 

However, the spelling "Alemannic" seems to be far more common than 
Alemanic. I'm wondering if that's a spelling mistake on SIL that I copied 
over assuming that resource to be authorative. If I were submitting this 
application today, I would use the spelling with two n's.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384

Peter Constable <[email-masked]> 
Sent by: [email-masked]
12/04/2006 08:28 AM

To
<[email-masked]>
cc

Subject
RE: Alemanic & Swiss German

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] On Behalf Of Doug Ewell

> Rather, the debate is whether "gsw" represents only Schwyzerdütsch per
> se, or other "Alemanic" languages and/or dialects which are not usually
> identified as Schwyzerdütsch, such as Swabian. 

That is not under debate. The ID "gsw" denotes precisely one individual 
language, which in English is commonly referred to as "Swiss German".

What is under debate is the name "Alemanic". It is a name used to refer to 
a collection of languages constituting a genetic subnode of Germanic. For 
that reason, Mark feels it is not appropriate to list "Alemanic" as a 
name.

I agree with Mark on the principle, that an ID should mean one thing only: 
either it means an individual language, or it means a collection of 
languages, but it does not mean both.

But what is unclear to me is whether the lexeme "Alemanic" has two 
distinct senses. Ethnologue indicates that the individual language denoted 
by "gsw" is referred to by Germanic-speaking peoples as "Schwyzerdütsch" 
within Switzerland but elsewhere as "Alemanisch". In other words, 
"Alemanisch" is a Germanic name for the individual language denoted by 
"gsw". That suggests the possibility that "Alemanic" might similarly be 
used with the meaning of that individual language.

If "Alemanic" is ever used with that sense, I think I can agree with Mark 
that it is not commonly used as the English name for the individual 
language in question, whereas it is commonly used for the collection of 
related languages. Thus, I will agree with Mark that it is at best 
misleading to list "Alemanic" as an English name for this individual 
language.

> Unless this thread has something to do with adding or changing an entry
> in the Registry, I agree with Michael that it should be confined to
> LTRU, and will post any future comments only to that list.

This thread very much has to do with entries in the Registry and is really 
out of scope for LTRU.

Peter Constable
_______________________________________________
Ietf-languages mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 6 Dec 2006 06:58:11 -0800

Gerard Meijssen <gerardm at wiktionaryz dot org> wrote:

> The Google presentation gives you a reality check; only 15% of the 
> content is tagged and often incorrectly. This means to me that the 
> codes are not understood / adhered to. My problem is that in the 
> Wikimedia Foundation we do not tag our content correctly and as it is 
> on the Internet, we need to know what the IANA language tags and I 
> have already matched 209 out of 250 WMF project codes.

I have tried to explain this at least twice already:

There is a revision of RFC 4646 underway that will incorporate ISO 639-3 
code elements.  It is likely to be approved some time early in 2007.  At 
that time you can use ISO 639-3 code elements and be conformant with the 
IETF specification as well.

There is no "conflict" between ISO 639-3 and the "IANA language tags" 
except that the latter cannot reference a draft standard.

> For WiktionaryZ we have as a first step created language portals for 
> almost all languages that are in ISO-639-3. As a resource it is on the 
> Internet and we do where applicable use the same conventions to 
> indicate locales scripts etcetera. We can and want to add the other 
> applicable codes that exist like MARC and IANA language subtags.

Since you're interested in being able to tag your content conformantly, 
why don't you join the LTRU Working Group and follow the progress of RFC 
4646bis?

>> 1.  The "backward compatibility" of RFC 4646 and 4646bis is a major 
>> design goal.  There are many systems that use RFC 3066 tags and 
>> breaking compatibility with it, in particular by replacing 2-letter 
>> subtags such as "nl" with the 3 letter-equivalent "nld", is a 
>> non-starter.
>
> This seems to be an excellent design goal from an engineering point of 
> view.

Well, it is the Internet *Engineering* Task Force.

> From a marketing point of view, I would say that it is a unmitigated 
> disaster. With only 15% of the Internet content tagged at all and much 
> of it wrong it looks like you are building on top on quicksand.

I do not follow your line of reasoning that a marketing "disaster" 
implies a defect in the engineering.

> I have already spend a lot of time trying to understand it and the way 
> it works seems Byzantine to me.

Please ask us questions about details of how to implement RFC 4646. 
That is likely to give you better results and less frustration than 
badmouthing the system.

> For me the goal of a new Standard should be to improve the 15% to 
> better than 75% but this 75% being correctly used code.

Ask anyone who has worked with Internet standards -- hardware or 
software -- and they will tell you they have little or no control over 
whether their standards are implemented correctly.  Only market forces 
can do that.  The IETF is explicitly an engineering group, not an 
industry consortium or a marketing advocacy group.

That said, if you see any engineering flaws in RFC 4646 that you feel 
contribute to low acceptance in the market, please state them.

> This means make we need the code to be credible and relevant.

How do you see RFC 4646 as not credible or not relevant?  (Other than 
not incorporating a draft standard, that is.)

> There is a need for a Standard that adds value; WiktionaryZ for 
> instance is likely to get content in the bnx language. This language 
> has no presence on the Internet yet and it is unlikely to be found by 
> search engines. For this it is really relevant to have a proper code 
> because this will facilitate the recognition of these rare materials. 
> If anything, success is in the long tail where you can make easy 
> converts. For this the ISO-639-3 though not ratified is useful and 
> therefore it has a credibility that the RFC 4646 lacks.

*sigh*
When RFC 4646bis is published, you will be able to conform to both at 
once.  If you check the draft Registry for RFC 4646bis (page 114), you 
will see than "bnx" and thousands of others are included.  (Warning: 
this is a large diocument, over 750,00 bytes.)

http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-00.txt

>    * There is the obvious need for identifying languages like
>      Bangubangu which is not met.

Is this the first time you have had to wait for a specification to be 
approved?

>    * There is the need to know how the ISO-639-3 codes will relate
>      to the IANA language tags.

They will be primary language subtags, except for those ISO 639-3 codes 
which are encompassed by an ISO 639-3 macrolanguage; those will be 
"extended language subtags" and will follow the macrolanguage; thus 
"qu-qxc" for Chincha Quechua.  Did that make sense?  It should if you 
have read RFC 4646 and ISO 639-3 and understand how they work.

> Having it only addressed from a technical point of view does not make 
> it work. We need to make it easy for people to tag the correct 
> language to their content.

Tools will help with that.  Market forces will help.  We are the ones 
designing the protocol and while some of us have also built tools, we 
are not in charge of marketing them.

You might see some familiar corporate domain names on this list, such as 
Microsoft and Google and Yahoo!, but the people on this list who work at 
those companies are engineers trying to solve engineering problems. 
Steve Ballmer is not on this list.

> Computers are clever, they can easily shift from one code to another.

Tagged content does not automatically get retagged when a code gets 
changed; someone has to retag it.  That is why compatibility is 
important.

> Well, I can remember discussions where people insist zh being a 
> language while it clearly is not from a linguistic point of view.

ISO 639-3, which you hold in high regard, considers Chinese to be 
simultaneously (a) a language and (b) an umbrella term for a group of 
more specific languages.  That is essentially how RFC 4646bis will treat 
it.  If you are not happy with this situation, you can use the ISO 639-3 
individual codes directly (or use private-use tags, or invent your own 
system).  But you cannot continue to say it is not clear how RFC 4646bis 
will handle this; I and others have explained it repeatedly.

Please join the LTRU Working Group and continue this discussion there. 
This list is for discussion of proposals to register new subtags, not 
for extended debates about the merits of the RFC 4646 system.