Wiktionary talk:About sign languages/Archive 1
This should probably link to the WT:BP conversation. --Connel MacKenzie 23:04, 13 September 2007 (UTC)
Unicode notations
Note in developing this policy page that there are at least two different ways English Wiktionary will use Unicode notations of sign language signs:
- To describe the sign in detail, similar to how we use IPA to transcribe pronunciations of words in spoken languages.
- To transliterate signs loosely but canonically to determine the appropriate title of each sign language entry.
Stokoe notation was once the only widely-known option for transcribing sign language signs in Unicode, but a more recent publication by Liddell and Johnson covers more detail of each sign and is not quite so biased toward ASL. Rod (A. Smith) 23:45, 13 September 2007 (UTC)
Index:American Sign Language (et al.)
There is definitely no consensus on how to include SL entries, and I, for one, think it's an intractable problem. But we have SL translations and can certainly have more. Can we list these at Index:American Sign Language (et al.), with a note like "Due to technical problems, there's no entry for these words, but they are listed as translations of English words."?—msh210℠ 18:08, 20 September 2007 (UTC)
Stokoe
Stokoe is problematic: it uses characters and forms that can't be used in a page title. (, #) and super and subscripts. (Why people who design transcriptions of all kinds feel so compelled to use obscure or odd characters is beyond me!)
It would be very good if there was a usable transcription, but I don't know of one.
An idea might be to re-transcribe the Stokoe into a usable set, use that as the page title and then link it with the Stokoe shown as the text of the link. But I haven't really thought this through.
No one has a better system? You'd think someone would! Robert Ullmann 17:28, 1 November 2007 (UTC)
- Rodasmith, above, q.v., mentions one by Liddell and Johnson.—msh210℠ 17:36, 1 November 2007 (UTC)
- Why can't we use commonly accepted English translations for the sign as the title (Boy, Girl, Women, Dad)? I understand that would have problems and limitations but why can't we use that until we can figure out another system? --Zoohouse 19:51, 16 February 2008 (UTC)
- In my opinion -- for what it's worth -- the problems outweigh the benefits.—msh210℠ 17:10, 19 February 2008 (UTC)
- What would be the problems? --Zoohouse 19:39, 7 March 2008 (UTC)?
- See below. Rod (A. Smith) 01:47, 6 July 2008 (UTC)
- What would be the problems? --Zoohouse 19:39, 7 March 2008 (UTC)?
- In my opinion -- for what it's worth -- the problems outweigh the benefits.—msh210℠ 17:10, 19 February 2008 (UTC)
Suggested naming scheme
An important aspect of an entry title is that it allow a reader to look up an entry upon encountering the word. Imagine someone sees a sign made by holding the B shape near the chest, then circling the chest with it, ending in a brief hold at the chest. If we choose English translations as the titles of sign language entries, readers will be unable to look up a sign upon encountering it for the first time. If we use a notational system that encodes high-level elements of each sign in a consistent way, readers will be able to locate the entry for such a sign and determine its meaning. Systems like Sign Writing don't use Unicode, so they're out. The system by Liddell and Johnson appears to be rather verbose, too much to be suitable for entry titles. I suggest we modify Stokoe notation to be compatible with Mediawiki and easy to type on a keyboard. Following are the details of my suggestion:
- All signs shall be given titles of the form location-handshape-motion to represent the initial location, handshape, and motion (or orientation if no motion is involved) of a sign.
Since such a system is not terribly precise, there will frequently be multiple signs described by a given tab-dez-sig sequence. Those will be treated like homonyms, and each will get its own complete entry on the shared page for that tab-dez-sig.
In entry titles, the location of the dominant hand at beginning of the sign shall be given as one of the following:
| Location symbol | Description |
|---|---|
| neutral | neutral location |
| whole-face | face, or whole head (symbol is superimposed ᴖ and ᴗ) |
| upper-face | forehead, brow, or upper face |
| mid-face | eyes, nose, or mid face |
| lower-face | lips, chin, or lower face |
| side-face | cheek, temple, ear, or side face |
| neck | neck |
| trunk | shoulders, chest, trunk |
| upper-arm | upper arm |
| forearm | elbow, forearm |
| inside-wrist | inside of wrist |
| back-wrist | back of wrist |
In entry titles, the handshape of the dominant hand at the beginning of the sign shall be one of the following:
| Handshape symbol | Description |
|---|---|
| A | fist (as ASL 'a', 's', or 't') |
| B | flat hand (as ASL 'b' or '4') |
| 5 | spread hand (as ASL '5') |
| C | cupped hand (as ASL 'c', or more open) |
| E | claw hand (as ASL 'e', or more clawlike) |
| F | okay hand (as ASL 'f'; thumb & index touch or cross) |
| G | pointing hand (as ASL 'g' 'd' or '1') |
| H | index + middle fingers together (as ASL 'h,' 'n' or 'u') |
| I | pinkie (as ASL 'i') |
| K | thumb touches middle finger of V (as ASL 'k' or 'p') |
| L | angle hand, thumb + index (as ASL 'l') |
| 3 | vehicle classifier hand, thumb + index + middle fingers (as ASL '3') |
| O | tapered hand, fingers curved over thumb (as ASL 'o' or 'm') |
| R | crossed fingers (as ASL 'r') |
| V | spread index + middle fingers (as ASL 'v') |
| W | thumb touches pinkie (as ASL 'w') |
| X | hook (as ASL 'x') |
| Y | horns (as ASL 'y', or as index + pinkie) |
| 8 | bent middle finger; may touch thumb (as ASL '8' in the latter case; this is a common allophone of Y) |
In entry titles, the first motion (or orientation if there is no motion) of the sign shall be one of the following:
| Motion/orientation Symbol | Description |
|---|---|
| up | moving, facing, or pointing upward (including "supinate", palm upward) |
| down | moving, facing, or pointing downward (including "pronate", palm downward) |
| up-down | moving up and down |
| dominant | moving or facing toward the dominant side |
| weak | moving or facing toward the center or non-dominant side |
| side-side | moving from side to side |
| to | moving or facing toward the signer |
| away | moving or facing away from signer |
| to-away | moving toward and from the signer |
| twist | twisting the wrist back & forth |
| bend | nod hand, bend or bent wrist |
| open | open up |
| close | closed |
| wriggle | wriggle fingers |
| circle | circle clockwise or counter-clockwise |
| together | approach, move together, near |
| touch | contact, touch, touching |
| link | link, grasp, or linked |
| cross | cross or crossed |
| in | enter, inside |
| separate | separate |
| exchange | exchange positions |
I've used the above title encoding in the entry (deprecated template usage) trunk-B-circle. That entry obviously needs images, but hopefully it gets the point across. Notice how it should be relatively easy for a reader to locate an entry based only on seeing the sign, without any prior knowledge of its meaning. Rod (A. Smith) 01:47, 6 July 2008 (UTC)
- Also note that the naming scheme is somewhat complementary to the indexing scheme rooted at Index:American Sign Language, since index pages like Index:American Sign Language/one-handed/B and Index:American Sign Language/two-handed/open A specify the number of hands and a more detailed handshape, while the entry naming scheme specifies where the sign is made and its initial movement/orientation. Rod (A. Smith) 16:43, 7 July 2008 (UTC)
- Wow, thanks for "being bold", Rod. While this system is not perfect (obviously, in a perfect world, we'd have the signs themselves as the PAGENAME, which is impossible), it is as good as anything else suggested, and has the added benefit that someone is actually doing something about it.
;-)Might I just add that there is some talk in the SL community of getting SignWriting to be a Unicode block. I don't know how soon that may happen, but if and when it does, we may wish to move all these entries. For the mean while, though, I think it's good the way it is. I know tab-dez-sig is traditional; but are these specific values of those three parameters also traditional, or did you make them up?—msh210℠ 17:27, 7 July 2008 (UTC)
- I didn't know about the initiative to add SignWriting to Unicode. I look forward to that, and yes, we should definitely move sign language entries to their SignWriting titles when Unicode, Mediawiki, and most web browsers support them. The specific values I chose above are my own invented English mnemonics of the symbols used in Stokoe notation. I'd have used one of the standard ASCII standards, but the ASCII standards I found use symbols that Mediawiki doesn't support in entry names ("", "<", ">", etc.). And, I figured, the audience for the English Wiktionary knows English already, so English words seems appropriate. I can't find any standard that uses English words, so I just chose common, short words that represent the general locations/movement/orientations. I certainly welcome any suggestions for shorter, more accurate, less ambiguous, or previously published values. Rod (A. Smith) 21:40, 7 July 2008 (UTC)
- Signwriting has been added as a script code (ISO 15924) Sgnw. A proposed code block is in the "roadmap", starting at U+1D800 (e.g. on plane 1) but there is no proposed draft for the codepoints. This means it is probably a minimum of two years away, but OTOH can be expected to happen. Whether it will be usable in a linear representation remains to be seen. The copyright and control by Sutton is a serious problem; Sutton has not to my knowledge made any public domain or GFDL etc material available; and since it is a novel system, one can't claim it is free of copyright (as with, say, hieroglyphs or French ;-). (*sigh*) So for example, even though there are dictionaries on the site for free download, they are copyright, so one can't copy entries. Robert Ullmann 17:28, 8 July 2008 (UTC)
- Valerie Sutton has released the latest symbol set called the International SignWriting Alphabet (ISWA) 2008 under the open font license. The ISWA 2008 is a double octet coded character set. The code pages are available. The proposed UTF code block has been available for several years but there is no active development for a solution using it. Steve Slevinski has a proof of concept for the SignWriting MediaWiki Plugin that will be released under the GPL3. We're getting there slowly. Regards, -Steve 19:14, 30 October 2008 (UTC)
- Stupid question: does MediaWiki support non-BMP codepoints in entry titles? My impression was that it didn't. For example, U+1D800 is %E0%9D%A0%80 in URI-encoded UTF-8 (at least, I think it is — I did that manually, which is not how it's meant to be done ;-)), and http://en.wiktionary.orghttps://dictious.com/en/%E0%9D%A0%80 redirects to http://en.wiktionary.orghttps://dictious.com/en/%C3%A0%C2%A0%E2%82%AC (U+00E0, U+00A0, U+20AC — so apparently it's interpreting it as URI-encoded Windows-1252 and discarding the x9D). Though I suppose it's not worth worrying about, since even if it doesn't now, there's no reason to think that won't be fixed between now and when the codepoints are assigned, anyway. —RuakhTALK 18:34, 8 July 2008 (UTC)
- Sure: 𒂍. or 𢄓. Full UTF-8 and ISO 10646-31. But the WP/Python code in 16 bit mode only supports up to U+10FFFF, however that is plenty for now. U+18D00 is F0 9D A0 80 in UTF-8: http://en.wiktionary.orghttps://dictious.com/en/%F0%9D%A0%80 which works fine. (You lost a bit in the first octet. ;-) Robert Ullmann 23:56, 8 July 2008 (UTC)
- Whoopsie, I'm so unused to non-BMP UTF-8 that apparently I can only count to three now. :-P Unicode only goes up to U+10FFFF, and ISO 10646 is supposed to be synched with Unicode now, so in theory that should permanently be plenty. Sorry for the false alarm. :-) —RuakhTALK 02:01, 9 July 2008 (UTC)
- Another point: Your handshape names are very ASL-centric, which is not a good thing. This proposal is still better than what we've had hitherto, of course. (I know they come form Stokoe, but that was written for ASL, IINM.) (And, incidentally, I like "up-down" beter than "bounce", which latter gives an impression of sharp movements (down-up, then hold slightly, down-up then hold slightly) whereas the former has no such implication AFAICT.)—msh210℠ 16:04, 8 July 2008 (UTC)
- I'm not sure what to do about the ASL bias. Do you know of a set of shape names that's less biased toward ASL? Regarding "bounce" etc., I may have taken the push to eliminate dashes too far. Given that there are no dashes in the first or second fields, any dashes in the last field are probably harmless. Robert, do you have any thoughts about whether dashes in the final "movement" field are to be avoided? Rod (A. Smith) 16:13, 8 July 2008 (UTC)
- The way I see this is that there are two levels: people who know how to do simple things in code (find the first hyphen, then find another one), and people who know regex fairly well
(+)-()-(+)in the first case having tab be one word is helpful, in the second case it doesn't matter. In neither case do hyphens in sig matter. And I do concur that "up-down" is better than "bounce". Robert Ullmann 16:39, 8 July 2008 (UTC)
- The way I see this is that there are two levels: people who know how to do simple things in code (find the first hyphen, then find another one), and people who know regex fairly well
- I don't know what to do abut the ASL bias, either. I was just bringing it up. I asked recently on a Usenet group devoted to linguistics and on a listserv devoted to sign-language linguistics whether there are language-neutral handshape names. I did not get any "yes" response.—msh210℠ 17:03, 8 July 2008 (UTC)
- Following moved from WT:TR#a word meaning "to move to and fro":
I'm looking for a short, single English word to serve as a mnemonic for the act of moving to and fro, specifically forward and backward as opposed to side-to-side. (deprecated template usage) ping pong is out because it's two words. (deprecated template usage) tennis is the best I've been able to think of. Can anyone do any better? The word would replace "to-away" in the title naming scheme on Wiktionary:About sign languages. Rod (A. Smith) 05:51, 8 July 2008 (UTC)
- How about (deprecated template usage) saw, as in the fore-back motion of (deprecated template usage) sawing? --EncycloPetey 07:35, 8 July 2008 (UTC)
- Is there any ASL word that's (1) very common and (2) particularly characteristic of such motion, and whose meaning is such that the motion makes sense? If so, maybe go with its English translation? —RuakhTALK 17:04, 8 July 2008 (UTC)
- Good ideas, both of you. Further discussion on Wiktionary talk:About sign languages, though, reveals that it isn't so important to eliminate the dash in the motion component of sign language entries. It seems we'll stay with -up-down rather than my hasty change to *-bounce, which had the unwanted connotation of a jerky motion. It's probably best to avoid ASL bias anyway, so since -up-down matches naturally with -up and -down, it now seems best to leave -to-away as is, matching -to and -away. (For what it's worth, an ASL bias applied to -saw might conjure up the sign (deprecated template usage) trunk-A-sides, which is made with the dominant hand in a fist moving side-to-side over the non-dominant hand held flat, as if the dominant hand holds the handle of a saw, cutting through wood represented by the other hand.) Thanks for your both of your suggestions, though. Rod (A. Smith) 17:40, 8 July 2008 (UTC)
Shall we use the word "wobble" "pendulate"
- Unfortunately, neither of those words describes the direction of motion, and "wobble" would probably be read to mean the wrong motion anyway, one that we're describing as "wiggle". Further input is welcome, of course, but per Robert and Msh210, above, "to-away" is just fine and this turns out to be a non-problem after all. Rod (A. Smith) 06:24, 9 July 2008 (UTC)
- How about pushpull as a compound word? Or row? --Joe Webster 06:02, 9 July 2008 (UTC)
- "Pushpull" is pretty good, I'd say. It's a little longer than "to-away", but if others prefer it, I wouldn't oppose. Per Msh210 and Robert, above, though, there isn't really any need to eliminate the dash, so unless there's strong support for another option, I'll just leave it as it is. Rod (A. Smith) 06:24, 9 July 2008 (UTC)
- It has more letters, but less syllables. Looking at the chart above, wouldn't pull-push be more accurate? --Joe Webster 22:20, 10 July 2008 (UTC)
- In this broad sign language transcription system, the “to-away” value of the motion component means that there is a motion phoneme to the sign wherein dominant hand moves in two different directions: toward the signer and away from the signer. It purposely does not specify which motion occurs first, nor how many times the motion repeats. The reason it doesn't specify the order is that, for most signs that move both forward and backward the order is not phonemically contrastive (er, at least it's not in ASL, and I assume that rule applies to other languages). That is, if I sign (deprecated template usage) lips-O-close to-away lips-O-close in ASL, it doesn't really matter whether the first motion is toward or away from my lips, so long as I make the right shape in the right place, in the right orientation, and move my hand in both directions. Hope that makes sense. Rod (A. Smith) 22:57, 10 July 2008 (UTC)
Wiksign
I still don't think we should list signs under their glosses; I'm just noting that the online LSF wiki-dictionary (competition!) Wiksign does so. Of course, they don't have spoken-language entries under the same titles. They use MediaWiki, which makes navigation familiar to our users; check it out. Their content seems to be cc-by-sa, but I'm not sure whether that includes the images and videos; if so, then, as far as I can tell, we can use those images and videos on Commons and here.—msh210℠ 18:11, 14 April 2008 (UTC)
Production header
I presume this is placed exactly as Pronunciation is? Rod: You might want to add it to the last table in User:AutoFormat/Headers. Copy the table line for "Pronunciation", but add the NS flag. (It also has to be in "TOS" in the code, which I've done, put will not be effective unless it is in the table. TOS is the set of L3 headers that occur before POS, at "top of section" ;-)
If you end up with a different header, we can easily switch it. It seems just a little odd to me, but I can't quite place why (;-), some connotation I am thinking of? Doesn't matter now. Robert Ullmann 15:56, 7 July 2008 (UTC)
- You presume right. Should I add the header to User:AutoFormat/Headers now or wait for further feedback about the somewhat arbitrary choice of "production"? The entries so far are still rough examples (missing such crucial elements as images, although it seems I might have a few native volunteers), so someone might find a better heading as we flesh them out. Rod (A. Smith) 16:29, 7 July 2008 (UTC)
- Fairly harmless to add it. Easy to change again. Do poke me if you decide on something else so I can change the internal table (which I really ought to "export" to the control file, and read with the other flags ...) FYI as of 13 June, there were no L3 "Production" headers in the wikt; so it doesn't conflict with any other use floating around. Robert Ullmann 17:02, 7 July 2008 (UTC)
- Whatever we end up with will need approval by vote, since it'll amend ELE, no?—msh210℠ 17:22, 7 July 2008 (UTC)
- Yes. What happens is that we get a fairly serious draft of this page (the project page) and take a vote on adopting it. It would then specify that "Production" is used only in sign languages. (The header might be voted on separately if needed, but there will be other things, like the entry naming. ;-). For now, this is about not having AF flag it, and also having it understand that it nests with multiple etys under the same rules as "Pronunciation". — This unsigned comment was added by Robert Ullmann (talk • contribs).
- OK. "Production" is now in AF's non-standard headers table. Rod (A. Smith) 21:40, 7 July 2008 (UTC)
Hyphens
Using the same punctuation within the symbols as to separate tab-dez-sig makes it harder to take them apart. Or may not be an issue at all, and the visual effect better.
Using hyphens which are common in English and other language increases the potential collisions. Which is, of course, no more terrible than any two languages, and the particular form (-A- in the middle) reduces it quite a bit. OTOH, these may be kind of confusing too. But might be thought about. Either function might be another character, including space. Just thinking about it Robert Ullmann 16:10, 7 July 2008 (UTC)
- Good thoughts. When I realized that we'll include phrases like (deprecated template usage) trunk-A-supinate neutral-G-away, I chose hyphen so that space could separate consecutive signs, but I'm not committed to that decision. Perhaps spaces could be used within a sign, while comma followed by space could separate signs within a phrase? Open to suggestions. Rod (A. Smith) 16:29, 7 July 2008 (UTC)
- I'm satisfied with the punctuation and spacing the way you did it, Rod.—msh210℠ 17:22, 7 July 2008 (UTC)
- Indeed, it's not bad. Having signs be "words", e.g. not containing spaces and separated by spaces, is a good thing. (You both do realize that if this is at all successful, a lot of people may start writing this way? Even with homonyms, glosses or just context will serve to dab.)
- One possibility is to note that the hyphens between tab-dez-sig aren't required, dez is UC or numeric, the others are lc; we might write "trunkAopen trunkGaway" (not as pretty though ;-). And/or tab and sig might use contractions. Just thoughts. Robert Ullmann 17:43, 7 July 2008 (UTC)
- I wish there were a common, single English word for "upper arm", "back of wrist", and "inside of wrist". If there were, we could eliminate the dash in the Tab (location) component because the other dashy Tab values have relatively obvious dashless replacements. Then, the name would be easy to parse. I'll add a few more sample entries and then copy the above table to Wiktionary:About sign languages soon, knowing that we can still tweak it easily up until the policy approval vote. Rod (A. Smith) 21:40, 7 July 2008 (UTC)
- Just upper, back, and inside might be just fine. Yes that makes them a shade more opaque, but not too badly. And "side-side" could just be "sides" maybe? I don't want this to be forced. (and I adore "wriggle" ;-). AF is running on the new config. Robert Ullmann 23:45, 7 July 2008 (UTC)
- Thanks. I incorporated your suggestions, corrected "wriggle" to "wiggle" (-: or maybe we should keep "wriggle" since it's undeniably adorable ;-), and made a few other tweaks to the copy I added to the project page. Rod (A. Smith) 05:31, 8 July 2008 (UTC)
Example sentences
Based on the format for example sentences for Japanese entries, the example sentence for (deprecated template usage) B@RadialWrist-PalmAway Sidetoside is tentatively formatted as follows:
- busy
- 100px 100px 100px
- (deprecated template usage) Y@Jaw-PalmForward Y@Jaw-PalmForward (deprecated template usage) R@Chin R@Chin (deprecated template usage) B@RadialWrist-PalmForward-OpenB@CenterChesthigh-PalmDown Sidetoside
- “Yesterday, the restaurant was busy.”
- 100px 100px 100px
That is, the first line of the example shows a sequence of images, some of which may be animated, then the second line shows something meant to correspond to the transliteration of a Japanese example sentence, then the third line shows a loose translation using natural English syntax. (Of course, it may make more sense when I get the images in there, but hopefully the intent is clear.) I'm not sure that's the best approach, so I hereby welcome any suggestions for improvement. Rod (A. Smith) 22:06, 9 July 2008 (UTC)
Hold-movement notation
Hold-movement notation is the system described in the Liddell and Johnson publication mentioned above in #Unicode notations. It is a successor to the traditional tab-dez-sig description used in the various versions of Stokoe notation, and now that I have a better understanding of it, I realize it's not necessarily as verbose as the first presentation I saw of it, so it's worth discussing whether we should adopt a variation of it for page titles.
Hold-movement notation breaks signs into something analogous to syllables (consisting of vowels and consonants) of spoken languages. Each hold can be described by a tab-dez-sig sequence using only orientation values in the sig component, and each movement can be described by one of the sig values for movement. Apparently, most individual words in ASL (and I presume in other sign languages), are of the form Hold-Movement-Hold. For example, the current entry (deprecated template usage) trunk-A-supinate could be encoded into hold-movement notation as trunk-A-touch supinate trunk-C-touch, which means, "hold dominant hand in A shape near the trunk touching non-dominant hand, then supinate the wrist, then hold dominant hand in C shape near the trunk touching non-dominant hand". As you can see, that's quite a bit more precise than "trunk-A-supinate". A phrase such as the one in the entry (deprecated template usage) trunk-A-supinate neutral-G-away would have a hold-movement notation like trunk-A-touch supinate trunk-C-touch diverge neutral-G-away. (Note: There are both advantages and disadvantages to the fact that one cannot necessarily determine where one sign ends and the next one begins in such phrase titles.)
This is still a somewhat low-resolution description, but it's quite a bit more precise than collapsing it down to a single tab-dez-sig for each sign. A very precise hold-movement description (like the ones I initially read) includes a finer division of hand shapes, details like continuity of the motion, extention of each digit, rotation of the thumb, non-manual signals, etc., and is normally presented in a table rather than a linear sequence. Low-resolution descriptions like trunk-A-touch supinate trunk-C-touch seem to me to be analogous to phonemic transcriptions of pronunciation, while high-resolution descriptions typically presented in tables seem analogous to narrow phonetic transcriptions.
So, it's now up to us to decide whether to use the very broad tab-dez-sig sequence in our entry titles or to make it a little more narrow and include holds and movements. Comments, questions? Rod (A. Smith) 16:59, 10 July 2008 (UTC)
- So you're saying we would not typically have entry titles like Au.BAFIcBAFI.INMPBAVP.Au.BAFIcm0ST.INMPBAVP_..._B~u.ULcUL.BKHPBAVP.B~u.ULcm0ST.BAHPBAVP_._1o-p.cm0ST.TIFIVPMP? Because that's well nigh unreadable.—msh210℠ 16:56, 17 July 2008 (UTC)
- As you can probably tell, I've been struggling to come up with a usable system. There are three competing forces at work: legibility, precision, and consistency with existing transcription systems. The tab-dez-sig system seems more readable at first glance, but is imprecise and could not be bot-converted to sign writing if we later have that option (and I would argue that it's only readable once you've studied the system for long enough, as is the hold-move system). I tried another variation of the hold-move system to make it readable, but the page names grew very long. Maybe that's not a big deal, though. I appreciate your feedback and agree that it's hard to read without learning the system. I will soon have a variety of examples for us to compare here, including one that minimizes length and one that maximizes both legibility and precision at the cost of inreased length. Bear with me, and keep your comments coming. Rod (A. Smith)
Following are candidate pagename titles for the short ASL phrase with the English translation "How are you?":
- OpenA-OpenA-To-Supinate C-C-Up Neutral-1-Away
- Au.BKFIcBKFI.INMPBAVP.Au.cm0ST.INMPBAVP ... B~u.ULcUL.BKHPBAVP.B~u.ULcm0ST.BKHPBAVP . 1o-p.cm0ST.TIFIVPMP
- OpenA-Finger-InMplane-OpenA-Center-InMplane C-Ulnar-BackHplane-C-Center-BackHplane 1-Center-FingerVplane
The first candidate uses a modified version of Tab-dez-sig. It says this:
- “An unspecified part of the dominant hand is located at or near an unspecified part the nondominant hand shaped as or similar to an Open A. The dominant hand is shaped as or similar to an Open A. An unspecified part of the dominant hand is facing toward the signer with an unspecified orientation. Supinate the dominant hand (and perhaps do something with the nondominant hand).”
- “Then, an unspecified part of the dominant hand is located at or near an unspecified part of the nondominant hand shaped as or similar to a C. The dominant hand is shaped as or similar to a C. An unspecified part of the dominant hand is facing up with an unspecified orientation.”
- “Then, the dominant hand is in an unspecified location in space. The dominant hand is shaped as or similar to a 1. An unspecified part of the dominant hand is facing away from the signer with an unspecified orientation.”
The second candidate uses precise hold-movement notation to say this:
- “Hold the dominant hand with all finger pads contacting the palm and the thumb unopposed and open. The back of the fingers are in contact with the back of the fingers of the opposite hand. The inside of the hand is facing the midline plane and the base of the hand is oriented with the vertical plane. At the same time, hold the non-dominant with all finger pads contacting the palm and the thumb unopposed and open. The whole hand is contacting the location in space that is medially distant from the body, centered, and sternum height. The inside of the hand is facing the midline plane and the base of the hand is oriented with the vertical plane.”
- “Then, move both hands straight to the next hold.”
- “Then, hold the dominant hand with all four fingers together, mostly extended but lax (curved), and the thumb unopposed and open. The ulnar edge of the hand is in contact with the ulnar edge of the other hand. The back of the hand is facing the horizontal plane and the base of the hand is oriented with the vertical plane. At the same time, hold the nondominant hand with all four fingers together, mostly extended but lax (curved), and the thumb unopposed and open. The ulnar edge of the hand is in contact with the point in space that is medially distant from the body, centered, and at sternum height. The back of the hand is facing the horizontal plane below and the base of the hand is oriented with the vertical plane.”
- “Then, stop using the nondominant hand and move the dominant hand straight to the next hold.”
- “Hold the dominant hand with the index finger extended, the other fingers closed, the thumb opposed and its pad contacting the closed fingers on their radial edge. The whole hand is contacting the point in space medially distant from the body, centered, and at sternum height. The tip of the index finger is facing the vertical plane ahead and the whole hand is oriented with the midline plane.”
The third candidate uses a slightly less specific version of hold-movement notation (but still more precise than tab-dez-sig) to say this:
- “Hold the dominant hand in the open A shape. An unspecified part of teh hand is near or in contact with fingers of the nondominant hand. The inside of the hand is facing the midline plane with an unspecified orientation. At the same time, hold the nondominant hand in the open A shape. The hand is at or near a point in space centered with the body at an unspecified height. The inside of the hand is facing the midline plane with an unspecified orientation.”
- “Hold the dominant hand in the C shape. An unspecified part is near or in contact with the ulnar edge of the other hand. The back of the hand is facing the horizontal plane with an unspecified orientation.”
- “Hold the dominant hand in the 1 shape. The hand is near a point in space centered with the body at an unspecified height. The finger is facing the vertical plane ahead and an unspecified orientation.”
Note that all three systems require the reader to be familiar with the details in order to interpret it accurately, but some seem easier to learn than others. Seeking feedback. Rod (A. Smith) 19:31, 19 July 2008 (UTC)
Handshape symbols
In some sections above, some concern has been expressed regarding the bias of using Stokoe symbols for the names of handshapes here. There are at least two ways to address this bias:
- For each sign language, we could create a separate policy page that uses handshapes that are iconic for and phonemically contrastive in that language.
- We can treat handshape names as we do IPA characters, which use a single set of latin (roman) characters and variations thereof to transcribe sounds from languages that are often not written using those characters.
It turns out that most of the handshape symbols used in Stokoe notation correspond well to the majority of fingerspelling alphabets. According to http://www.sign-lang.uni-hamburg.de/intersign/Workshop2/Miller/Miller.html:
- Of the 44 countries or groups of countries surveyed in Carmel (1982), the vast majority share a significant number of handshape-character correspondences with the International and North American manual alphabets. (The principal differences between the two are that the North American handshapes corresponding to < F > and < T > are not used in the International alphabet since they are considered vulgar or obscene in many cultures)
- Among the roman-based one-handed manual alphabets, those showing the most important differences in correspondence values are the Spanish-based alphabets, the Swedish and the Portuguese (from which the former is derived); these alphabets, nonetheless, still share a significant proportion of handshapes with values identical to those in the North American and International alphabets. Surprisingly, even two-handed alphabets include some handshapes that correspond to International one-handed values. Manual counterparts of non-roman scripts such as the Chinese, Japanese and Indian Nagari fingerspelling systems and the Israeli, Greek, Thai and Russian alphabets are based to a surprisingly large extent on roman alphabet values. The only cases of complete non-correspondence with roman values are fingerspelling systems based on the Arabic alphabet, the Ethiopian syllabary and the Korean Hangul syllabary-alphabet: in each case, handshapes are more or less iconic representations of the characters in the writing system.
So, I'm thinking it's not so bad that the handshape names are based on ASL letters. If any particular sign language project begins here and its participants would prefer an entry naming system that uses different handshape symbols, that should be fine so long as they are chosen to be phonemically contrastive within the language. If that happens, though, I think we should still have a production section in entries for that language that describes the sign in common, sign-language-neutral terms, analogous to how we use IPA in the pronunciation sections of spoken language entries. Rod (A. Smith) 17:03, 11 July 2008 (UTC)
- Fwiw, I agree.—msh210℠ 17:57, 11 July 2008 (UTC)
strong and weak hands
I think they're usually called dominant and nondominant.—msh210℠ 17:12, 14 July 2008 (UTC)
- Noted and corrected. Rod (A. Smith) 23:02, 14 July 2008 (UTC)
- Fortunately, the entry pagename transcription system being proposed uses position rather than name to distinguish the dominant hand from the nondominant one, but for what it's worth, Padden and Perlmutter (1984) used the terms "strong" and "weak". It seems at least some other linguists are following that lead, but I don't know how exactly much uptake the new terms have enjoyed. Rod (A. Smith) 00:06, 16 July 2008 (UTC)
attestation
The current proposal says it differs from the "core CFI" as follows:
- For sign language entries, a term shall be included if it meets any of the following conditions
- ...
UsageUse or mention in permanently recorded media, conveying meaning, in at least three independent instances spanning at least a year.
Should that be
UsageUse or mention in permanently recorded media,conveying meaning,in at least three independent instances spanning at least a year.
? If not, can someone explain what a mention conveying meaning is? (I thought "use... conveying meaning" was merely belt and suspenders.)—msh210℠ 20:53, 26 August 2008 (UTC)
- Yeah, I think the "conveying meaning" phrase of WT:CFI is a bit strange. Apparently, it's meant to ensure that we don't include common meaningless strings of arbitrary symbols, e.g. (deprecated template usage) 9a1, on the sole grounds that short strings get lots of search engine hits without their authors sharing any common definition. I'd support rewording the phrase in WT:CFI, but doesn't that seem more an issue with WT:CFI than with a language-specific policy page? Rod (A. Smith) 06:11, 27 August 2008 (UTC)
- As I understand it, “use…conveying meaning” has two purposes:
- use
- It actually be used in a sentence, not just defined: Use–mention distinction
- conveying meaning
- Ensure that the use be illustrative, more about evaluating if something is a good example sentence – so that it’s clear from context what meaning it has – so that someone reading the sentence can see that the word means this and not that.
- As a simple example, “I like strawberries.” does not convey meaning – it could be anything, but “We went strawberry picking.” conveys that it’s a fruit.
- Nils von Barth (nbarth) (talk) 10:25, 31 August 2008 (UTC)
- Typo corrected – Nils von Barth (nbarth) (talk) 10:26, 31 August 2008 (UTC)
- As I understand it, “use…conveying meaning” has two purposes:
- My understanding is basically the same as msh210's. I think ] is pretty clear about what it means. (BTW, it looks like all of you take the word "usage" to refer to the use–mention distinction, but I'm not so sure it does. Who ever heard of the "usage–mention distinction"?) —RuakhTALK 15:57, 8 September 2008 (UTC)
Policy vote detail
I think you may want to have the vote on specific elements, not on accepting the page as policy in entire. I.e. vote on including sign, using transcriptions as entry titles, using the Production header. If the vote is on the page, you are going to have to have a new vote every time you want to update/modify the tables. Not what you intend I think. Perhaps "refactor" the page so the first section/division is the policy, and the remainder explicitly says it can continue to be updated? Or something. Robert Ullmann 11:31, 8 September 2008 (UTC)
- Ah. If your interpretation of the current vote is that it includes a locking-down of the transcluded sections, then I haven't done this right. I did intend to allow extension without another vote. I'll refactor it after work this evening (Pacific time). Rod (A. Smith) 14:21, 8 September 2008 (UTC)
- I've begun the refactor. Hopefully it is now clear which parts are extensible without a vote. Does the issue seem resolved? Rod (A. Smith) 04:37, 9 September 2008 (UTC)
English
Suppose one of the people I am working with here wants to add Kenyan Sign (isk IIRC) to the Swahili wiktionary. What entry titles would we use?
If we use Swahili equivalents, then the same sign (whether for Kenyan or American Sign) doesn't get linked with iwikis, it is a different "word". And a table of equivalents is then needed for each (non-sign) language.
If we use the English for all sign languages in all wikts, then it will all work, but is very English centric. (Although this might be okay.) After all, there isn't anything particularly "Swahili" about Kenyan Sign, any more than American Sign is associated with English.
Keep in mind that the other language wikts copy a lot of ideas, design, and structure from the en.wikt; undoubtedly they will want to import sign entries and use the methods for other sign languages. Should it all be English naming? Or what should they do? Robert Ullmann 11:58, 8 September 2008 (UTC)
- It makes sense that the Swahili Wiktionary wouldn't use "CenterChesthigh" in an entry title. Symbols could be an alternative to the English words used in the entry pagenames, but User:Msh210 noted above that symbols are "well nigh unreadable", so I created the current candidate version as a readable alternative. Unfortunately, the current version is only readable to someone who knows English. Following are some different transcription approaches for the entry (deprecated template usage) BentB@BackFinger-PalmBack-BentB@CenterChesthigh-PalmBack C@Ulnar-PalmUp-C@CenterChesthigh-PalmUp 1@CenterChesthigh-TipFingerForward:
- Stokoe symbols: (deprecated template usage) A⊤*ɑ Cɑ* ØG< — This transcription cannot be used for Wiktionary entry names for obvious reasons.
- Stokoe English: (deprecated template usage) OpenA-OpenA-To-Supinate C-C-Up Neutral-1-Away — This is a bit more readable and technically feasible for entry names, but it's practically impossible to envision or produce the sign accurately given just those details. It also lacks the phonological basis that modern sign transcription systems have, so there could be no automated migration to a future transcription systems (e.g. SignWriting).
- Hold-move symbols: (deprecated template usage) Au.BKFIcBKFI.INMPBAVP.Au.cm0ST.INMPBAVP ... B~u.ULcUL.BKHPBAVP.B~u.ULcm0ST.BKHPBAVP . 1o-p.cm0ST.TIFIVPMP — This transcribes the sign as a series of phonemes. It contains most of the info needed to envision and produce the sign accurately and could be migrated by bot into a future transcription system. It's just not humanly readable.
- Hold-move English: (deprecated template usage) BentB@BackFinger-PalmBack-BentB@CenterChesthigh-PalmBack C@Ulnar-PalmUp-C@CenterChesthigh-PalmUp 1@CenterChesthigh-TipFingerForward — This is a pretty readable version of the transcription above. It captures enough of the sign details for a reader to envision and produce the sign accurately and for a bot to migrate into a future transcription system.
- I can't think of any way to make a transcription system that is (a) compatible with Mediawiki, (b) phonologically sound, (c) readable by humans, (d) migratable by bots, and (e) not English-centric. I believe the current proposal satisfies all the criteria except for e, as it is admittedly English-centric. It still has my support, but I welcome further comments. Rod (A. Smith) 04:15, 9 September 2008 (UTC)
- Once SignWriting is assigned to Unicode characters, we can use SignWriting pagenames, which will solve all problems except "(c) readable by humans", and will match a standard. Ru, who has experience with the RFC process at least, though I don't know about his Unicode experience, has said that that's likely to be a matter of just a couple of years (IIRC).—msh210℠ 17:47, 10 February 2009 (UTC)
Phone name for variable locations
Similar to our use of "someone" for variable pronouns in English entry names, many entries for signed languages have variable locations, e.g. pronouns that point to a person or thing. In the list of sign phone names for entry titles, the series Left1, Left2, Left3, Right1, Right2, Right3 was proposed as a way to describe such signs. To avoid duplication, though, I didn't use those phone names for pronoun entries like (deprecated template usage) [email protected] Nod. I used an ellipsis ("...") to represent such a variable location rather than create duplicate entries for each possible location. I'm not sure that an ellipsis is the best choice. Does anyone have any suggestions regarding how to represent a variable location in an entry pagename? —Rod (A. Smith) 19:43, 10 February 2009 (UTC)
- For context, consider the typical ASL verb X-GIVES-TO-Y. I would name it something like (deprecated template usage) [email protected]... RoundVert [email protected]..., where the first ellipsis is a variable location that indentifies x (the giver) because it is positioned between the signer and x, the second is a variable orientation that points toward x, and the other two ellipses are variables that identify y (the receiver). —Rod (A. Smith) 20:15, 11 February 2009 (UTC)
- I belatedly reached this argument just after I finished "fixing" your entries. I was under the impression that someone was taking the "..."'s in WP:ASL literally! In response to your proposal, I think the best way to do it would be to have a "main" entry for directional verbs (either you-VERB-me or I-VERB-you), and have a representative list under "Alternative forms". A complete list with Left3, Left2, ..., Right3 is not necessary (and in particular, every combination of different loci VERBing each other is certainly not necessary). An alternative form for the reflexive (they-VERB-each-other) would be good, though, as it is often morphologically different. The "..." in page titles is not a good idea, though, because it doesn't fit the pattern of the other pages. —Di gama (t • c • w) 02:39, 15 September 2009 (UTC)
- Those ellipses were nagging me. I agree with your sensible approach of selecting a neutral form for the lemma. Thank you. —Rod (A. Smith) 05:53, 15 September 2009 (UTC)
Production text changes
By e-mail, User:Positivesigner has suggested some improvements for the structure of the production text in ASL entries. Specifically, he says that the handshape descriptions obstruct the flow of text. He says they may be better as a footnote, e.g.:
- Posture the dominant hand in the “W” handshape in front of the upper chest, palm facing down. Posture the nondominant hand in the “open B” shape in front of the upper chest, palm facing up, just below the dominant hand. (The “W” handshape is the same as the “6” handshape, i.e. the thumb holding the little finger down, the other fingers extended and spread apart. The “open B” shape has the fingers extended and together, thumb extended to make a flat hand with a gap between the thumb and the edge of the hand, also known as “extended B” or “open hand.”)
I agree with his suggestion. In order to make such a change, I'll need to introduce some additional templates to output just the friendly name of each ASL phone and to change the wording in the existing production templates (e.g. {{ase-prod 1}}). Before I do that, I just wanted to post the idea here to see whether there were any objections.
Any objections? —Rod (A. Smith) 21:24, 10 September 2009 (UTC)
- My thoughts exactly. Particularly, I found it annoying to have a rather wordy explanation of how to make each hand duplicated verbatim when the same handshape is used by both hands or when the template is used for both stages of a movement and the handshapes don't change between them (which is true in the majority of cases). By comparison with a print dictionary, the idea is ridiculous. Obviously, we have more space to work with than they do, but conciseness is not necessarily a fault. I recommend we do away with them entirely, and instead link them to Wikipedia or our appendix. Example:
- This way, it doesn't get it the way, but it's still there if anyone needs it. Besides, if I'm browsing the dictionary, I get to terms with the lingo so that I understand the entries. I don't need a glossary for every page. Or, more likely, the readers are already somewhat ASL-conversant, and therefore already know the handshapes. —Di gama (t • c • w) 08:24, 15 September 2009 (UTC)
- Makes sense. Do you think this applies even to the relatively obscure handshapes, like "Small flat O", "Open M", and "Ru", or would it make sense to allow space at the top or bottom of the production text to explain handshapes whose names may be unfamiliar? (We could avoid repetition.) —Rod (A. Smith) 16:08, 15 September 2009 (UTC)
- Even those IMO.—msh210℠ 16:44, 15 September 2009 (UTC)
- OK. Modifying this idea for a less verbose format, I added a tool tip in this example change. Resulting entries look like this: 3@NearCenterChesthigh-PalmUp CirclesHoriz. Feedback? —Rod (A. Smith) 19:16, 15 September 2009 (UTC)
- Given that some movements have shapes I think "handshape" is better than "shape" in the short link text, so I'm moving in that direction (e.g.) unless any of you have different ideas. —Rod (A. Smith) 20:56, 15 September 2009 (UTC)
- I have added descriptions (ase-prod templates) to all "official" signs (I have been trying to coordinate the sign lists in their various forms to reflect the same set). Effectively, this means that "small flat O" is treated the same as "B" or "C". However, non-standard signs (like 1^o-f, Hu, and Ru), I think, should have a full description, or at least a description based on another sign (ex. Hu = "a version of the “3” shape where the index and middle fingers are together") which is inserted directly into the page. —Di gama (t • c • w) 23:56, 15 September 2009 (UTC)
- Even those IMO.—msh210℠ 16:44, 15 September 2009 (UTC)
- Makes sense. Do you think this applies even to the relatively obscure handshapes, like "Small flat O", "Open M", and "Ru", or would it make sense to allow space at the top or bottom of the production text to explain handshapes whose names may be unfamiliar? (We could avoid repetition.) —Rod (A. Smith) 16:08, 15 September 2009 (UTC)
- Thanks for adding those missing descriptions, Di gama. It's tough to settle on the list of handshapes to name because I don't have any reliable handshape frequency statistics. The shapes I'm least sure of now are OpenM and OpenN, which incidentally use "Open" differently from the other handshapes, where it indicates the thumb is unopposed. It's probably not a big deal to overload "Open", but I don't know how prevalent OpenM and OpenN are.
- For what it's worth, the MEXICO sign you mention is apparently on its way to the etymological dustbin. There are a few signs different ASL signs that mean "Mexico", but for languages and country names, ASL is trending toward adoption of the sign used by the prevalent sign language in the country. (E.g., (deprecated template usage) 1@Forehead-PalmForward from German Sign Language is replacing the colorful-looking (deprecated template usage) 5@RadialHand-PalmBack-5@CenterChesthigh-PalmBack Wiggle-Wiggle.) For "Mexico"/"Mexican", the new sign is (deprecated template usage) V@Sfhead-PalmDown Twist V@NearSfhead-PalmForward. I think I've seen a couple of signs using the OpenM shape, including (deprecated template usage) OpenM@Sfhead-FingerAcross OpenM@NearSfhead-FingerAcross and (deprecated template usage) OpenM@TipFinger-FingerAcross-OpenM@CenterChesthigh-FingerAcross OpenM@FromTipFinger-FingerAcross-OpenM@SideChesthigh-FingerAcross OpenM@FromTipFinger-FingerAcross-OpenM@SideTrunkhigh-FingerAcross. I suspect several other signs use that shape, but I don't know. And for OpenN, I think it's used in (deprecated template usage) H^o@NearFinger-OpenN@CenterChesthigh Contact H^op@NearTipFinger-OpenN@CenterChesthigh, although I might have transcribed that using the H shape if you hadn't added OpenN to the list.
- Anyway, should I add those two new shapes to the "Sign languages" section of MediaWiki:Edittools? —Rod (A. Smith) 16:52, 16 September 2009 (UTC)
- For now, I've at least partially followed your lead by removing BentL and adding OpenM to MediaWiki:Edittools. —Rod (A. Smith) 19:23, 16 September 2009 (UTC)
- The list of changes to the handshape list since I started modifying things (not all by me) is a follows (based on the old index list; it varied slightly from one source to another before I consoidated the differences):
- FlatF → Flat9, for consistency.
- remove OpenF, because I have never seen this handshape, and we don't have any examples.
- remove SmallFlatO, because although it is used occasionally, it is for the most part interchangeable with SmallO.
- add OpenM, for consistency with OpenN.
- About SmallO / SmallFlatO / ModX: this handshape (apparently) takes several different forms for different people. "ModX" (you might have seen this in the list if you were quick) represents a handshape like X, but with the thumb against the middle finger (like K). This is the way I and my dictionary do signs like "write". I didn't recognize SmallO until I saw that you use it for "write". The main morphological difference, I would say, is that "SmallO" has tips touching, whereas my handshape has the tip of the thumb against the pad of the index finger. The names illustrate this: I think of the sign as a version of "X", not "O". I don't know what you think, so I'll see that before I do anything on this front.
- OpenM and OpenN are versions of their respective letters with the fingers bent rather than closed. As to why I used "Open", it is the best word I can think of to describe their relations to M and N. Although it would be more technically correct to use "Bent", that would force me to use "BentW" and "BentH", which is confusing since W doesn't exist (and rightfully so, because this is the "W" from the hold-move charts: fingers together, not spread). And as to their use, they are most notable for their use when fingerspelling (especially when fingerspelling quickly). Although people tend to close their fists for "T", it is evidently too slow to close one's fist for M and N, and these shapes result. From this, they "bleed" into initialized signs (as you pointed out). I suspect that there are a considerable number of initialized signs both for M and OpenM (for example, I know that "Monday" uses "M", not "OpenM"). For more examples, a perusal of the dictionary yielded macaroni, macro, magnet, mainstream, maneuver, mask, master, mathematics, mature, and mayonnaise. Actually, although those signs claimed to use M hands, the open fingers were angled anywhere from 90° (W^o-f, current OpenM) to almost fully open (Wo-f). However, in all cases, the thumb and pinky were closed (the pinky's MCP is often unbent because of stress from the ring finger), and the three other fingers are together and unbent at the PIP and DIP, rather than bent as in "M". Another difference is that in "OpenN", the thumb touches the intermediate phalange of the ring finger (depending on the angle of the open fingers), rather than the proximal phalange in "N" (because "N" has the thumb separating the fingers, but "OpenN" has it restraining the closed fingers). Actually, "OpenM" is far more prevalent in initialized signs than "M" (if my dictionary is any indicator).
- With respect to Edittools, The order I have been using sorts by the base title, followed by the modifier if applicable (e.g. B, BentB, FlatB, OpenB, C), with ILY and Corna after the alphabet. Currently, this appears to be the case, but OpenN is missing. Other than that, it looks fine. PS: Take a look at the new
{{index/American Sign Language}}and tell me what you think. —Di gama (t • c • w) 10:05, 18 September 2009 (UTC)- Oh, yeah. I do make MATHEMATICS, and MASK with the OpenM shape, different from my M shape. I don't know the sign for "macaroni", "macro", "maneuver", or "mature". My MAGNET sign is (deprecated template usage) 5@NearPalm-PalmForward-FlatB@CenterChesthigh-PalmForward RoundVert FlatO@Palm-TipAcross-FlatB@CenterChesthigh-PalmForward. My MAINSTREAM sign is (deprecated template usage) 5@SideChesthigh-TipAcross-5@SideChesthigh-TipAcross RoundHoriz-RoundHoriz 5@Palm-PalmDownTipForward-5@DistalCenterChesthigh-PalmDownTipForward. For "master", I'd sign (deprecated template usage) Claw5@Shoulder-PalmDown Contact or (deprecated template usage) OpenA@SideChesthigh OpenA@SideNeckhigh, although I expect there is a specific sign for "master" that I just haven't seen. I assume MAYONAISE is like BUTTER, but with dominant hand as OpenM?
- I like the way you've cleaned up the index header. It would be nice to discuss this more and choose a single organization structure, as well as a definitive index entry format. I think there's a good balance somewhere between the minimalist category pages (e.g. Category:American Sign Language nouns) and the verbose version of the index pages (e.g. Index:American Sign Language/1DT). —Rod (A. Smith) 16:38, 18 September 2009 (UTC)
- The MAGNET and MAINSTREAM signs you mentioned are here also, as "alternative forms". The initialized MAGNET sign is (deprecated template usage) OpenM@InsideChesthigh-PalmDown-OpenM@InsideChesthigh-PalmDown Accel OpenM@BackFinger-PalmAcross-OpenM@CenterChesthigh-PalmAcross, and MAINSTREAM is (deprecated template usage) OpenM@SideChesthigh-TipAcross-OpenM@SideChesthigh-TipAcross RoundHoriz-RoundHoriz OpenM@Palm-PalmDownTipForward-OpenM@DistalCenterChesthigh-PalmDownTipForward. MAYO is just initialized BUTTER. Anyway, the point was to show that OpenM is in considerable use. (In fact, it is much harder to find "M" in initialized use!)
- Personally, I am leaning toward the "old" index, and not just because it is not in tatters. It makes more sense to me to sort first by dominant handshape. It is the most immediately obvious trait of a sign. I should point out, though, that this would throttle our identification of new "official" handshapes. If we have too many, we could cross the point at which the original signer wasn't paying enough attention to distinguish two similar handshapes, and we would be forced to have an "alternative form" between the two potentials, which would confuse things even more. As I mentioned on your talk page, the table-based alternative indices are attractive. What should really be done is to create our own templates for the index. This way, style changes can be done simultaneously over the whole index with little disturbance and hassle. In fact, I think I'll do that soon. If the table idea comes later on, then, the work will be minimal. —Di gama (t • c • w) 04:34, 19 September 2009 (UTC)
- I've added the necessary templates and converted Index:American Sign Language/1. I tried to keep UI changes to a minimum so it shouldn't look any different, but it's all templates in the back. My biggest worry now is that I've outsourced the headers into the templates. It doesn't appear to cause any rendering problems, but the section edit buttons are gone. Should I replace them programmatically or put the headers back? If we go the table route, the headers may be completely replaced by an in-table equivalent, so it might be necessary to keep them in the templates. What do you think? —Di gama (t • c • w) 09:03, 19 September 2009 (UTC)
- Thanks for adding those templates. I like the flexibility of using the template for the index entries, and that you included an {image} parameter. Given your feedback and e-mail conversations with Tom (Positivesigner), I'm leaning toward ordering index entries according to a strict, simple phonological ordering according to the official phones described in Appendix:Sign language entry names and using ASLSJ as guidelines for where to place "see also" links in index pages. For example, at the end of each section of index pages in the "D and T Group" from ASLSJ, we could add a compact list of "see also" links to the index pages for each of the other shapes in that group with otherwise matching phones. I don't think section edits are a big deal in the index pages. Eventually, the index pages should be maintained with a bot anyway, so section edit links are of limited value. —Rod (A. Smith) 16:06, 21 September 2009 (UTC)
- When you say "strict phonological ordering" do you mean alphabetical order for entry names? (i.e. 3@Chest < 3@Chin < 3@NearChest < 3@Sternum) Or do you mean a more complex method of comparison by attributes in the entry name? (i.e. 3@Chest < 3@NearChest < 3@Chin < 3@Sternum; note that NearChest comes after Chest) And would we use the 1DT-style pages or the handshape pages? Sorry, but I didn't quite understand what you meant. —Di gama (t • c • w) 13:19, 25 September 2009 (UTC)
- I just meant that phones written differently will sort separately (so 3@Chest* < 3@NearChest*), as opposed to the more complex sorting system required by the new super-phoneme index pages (wherein A@Chin-ORIENTATIONSUPERPHONEME1 < S@Chin-ORIENTATIONSUPERPHONEME1 < A@Chin-ORIENTATIONSUPERPHONEME2 < A@Chest* because A and S are of the same super-phoneme). Although I didn't declare how to order the phones with respect to each other, alphabetical sorting doesn't seem useful. I would probably order location phones so that those of similar height sort near each other. That approach may produce the sequence 3@Chin < 3@Sternum < 3@Chest < 3@NearChest (or the exact reverse of that). We should probably remove the super-phoneme index pages (e.g. "1DT") and fall back to the index pages based on plain handshape phones. When I get a little more time, I will try to summarize the various ideas and feedback for how to organize the index pages at Index talk:American Sign Language#Organization. —Rod (A. Smith) 16:29, 25 September 2009 (UTC)
Entry names for signs using both hands
The entry names for signs in which both hands are used could be clearer if a different separation symbol were used between handshapes. As an example, Open8@Finger-TipUp-Open8@CenterChesthigh-TipUp Contact.
The hyphen here is overloaded as a field separator for fields that define each handshape (Finger-TipUp) and as a section separator for each hand (TipUp-Open8). Visually the hyphens stick out better than the at symbol (@). So when I looking at this entry, I'm mentally looking for the following information.
1) Dominant hand Open8@
2) Non-dominant hand -TipUp-, Open8@
3) Location CenterChesthigh
4) Movement Contact
The space character (or underscore as read in the URL) is already used for step separation OpenB@NearSideNosehigh-FingerUp OpenB@SideNosehigh-FingerForward or consonant-vowel separation H@TipPalm-PalmDown-OpenB@CenterChesthigh-PalmUp Contact H@BasePalm H@TipPalm Contact H@BasePalm H@TipPalm Contact H@BasePalm. Would it be possible to find another symbol that directly refers to the start of the non-dominant hand description? A carrot perhaps?
Open8@Finger-TipUp^Open8@CenterChesthigh-TipUp Contact
H@TipPalm-PalmDown^OpenB@CenterChesthigh-PalmUp Contact H@BasePalm H@TipPalm Contact H@BasePalm H@TipPalm Contact H@BasePalm
It sounds like a subject for voting if options are presented. — This unsigned comment was added by Positivesigner (talk • contribs).
- I'm surprised that the hyphen stands out more for you than the at symbol. For me, the first thing that draws my eye in these entry names is the large at sign, and the number of hands is indicated by the number of at signs. That may be just me, though, so I'll let others chime in. —Rod (A. Smith) 16:05, 22 September 2009 (UTC)
- I'm coming from a slightly different angle, namely, the creation of the bot which Rod so frequently alludes to. I find that having the hyphen perform double duty makes it difficult for the bot when it tries to parse the entry name. Particularly since the hyphen performs triple duty (ex. 1@Chin-PalmDown-1^o-f@Chest), it is hard to figure out which is the hand-separator. Of course, as demonstrated in the example, the caret is also in use. What about colon or semicolon? —Di gama (t • c • w) 13:30, 25 September 2009 (UTC)
- Hmm. I suppose it would be a little easier for the writer of such a bot if a unique character indicates the start of the second hand of a two-handed sign. How about the plus sign ("+")? To me, that would seem to indicate the addition of a second hand. —Rod (A. Smith) 17:21, 25 September 2009 (UTC)
- Sounds good, since I don't think we use that symbol yet. However, there are some logistics in switching the symbol to anything else regardless, since it shows up more or less everywhere in our section of Wiktionary. If we do decide to do it, I think I will need to give my bot official bot status since it is likely to come into use soon. (PS: If it gets bot status, does that autoconfirm it too? since it will have to move pages.) —Di gama (t • c • w) 01:28, 28 September 2009 (UTC)
- I don't know whether bots automatically get autoconfirm, but yes, we'll need User:Di gama bot to do the actual moves. —Rod (A. Smith) 15:51, 28 September 2009 (UTC)
See ongoing discussion at Category talk:ase:English derivations. —Di gama (t • c • w) 03:19, 4 October 2009 (UTC)
I've created this entry with a definition line for the sense where '1' is used as a marker indicating a person. The definition line and part of speech may need fixing. (I listed it as a Noun. Pronoun may be better, or Particle perhaps.)—msh210℠ (talk) 18:49, 31 August 2010 (UTC)
SignWriting to replace our entry names?
Our original intent was that the made-up entry names we're using would be used only until such time as SignWriting (or Stokoe or something) made it into Unicode. (See 2008 discussion from ].) Well, SignWriting has been in Unicode for about a year, so should we convert our entries over? Pinging especially Rod, and I'll link to this discussion from the BP.—msh210℠ (talk) 09:07, 7 December 2016 (UTC)
- Oh, shoot, sorry for the false alarm. Apparently, it's still not doable: w:SignWriting#Unicode says that two-dimensional positioning is an essential part of SignWriting notation and is not included in Unicode (yet). I've rolled back my link to this discussion from the BP.—msh210℠ (talk) 09:20, 7 December 2016 (UTC)
- After playing around with some simple entries (see 𝠀 for a simple entry and 𝠞𝪁𝧨 for something a little more complex), I think we can use SignWriting now to replace our handshapes and some aspects of position and movement. Handshape updates alone would make our notation less ASL-specific, and any SignWriting we adopt will make our entries more iconic, so that seems like moving in the right direction. Certain aspects of orientation, position, and motion are not yet captured in the Unicode standard so wherever signs require such, we can continue to use our transliteration system, at least in our entry names. Not sure how well wiki tables can handle positioning for the ===Production=== sections. —Rod (A. Smith) 05:35, 19 February 2017 (UTC)
I acknowledge that SignWriting isn't yet ready to represent the proper production of a sign, but I think it's good enough to use for our entry names, at least it's more iconic and readable than what we have today, and it doesn't lose much that really matters for entry names. So let's move our entries to the SignWriting equivalent where possible. Note how Category:American Sign Language pronouns recent additions box shows a couple of readable SignWriting entries contrasted with long transcription system for older entries. Potential objections to renaming our entries might include availability of the SignWriting font (I expect it's widely enough available by Wiktionary users), availability of keyboard access, or objections related to character positioning (signs sit below linear text line, obscured in the entry headline by our "Contents" box). Any others? —ɹɑd ✍️ 16:46, 19 February 2017 (UTC)
- Actually, this may be a premature recommendation. It's not necessarily easy for editors and readers to install a SignWriting font. Android for one doesn't make it easy. —ɹɑd ✍️ 21:19, 19 February 2017 (UTC)
SignWriting still needs another year or two before it will be ready to be used for entry names. The current fonts are 1-dimensional only and require SVG for 2-dimensional placement. Additionally, the 672 approved Unicode characters only cover the individual symbols and do not deal with the 2-dimensional layout. Going forward, a 2-dimensional font is planned for SignWriting using the Universal Shaping Engine that will include a proposal for an additional 17 Unicode characters to handle layout. If you are interested in more detail, you can check out a Wikimedia grant proposal I wrote to cover the development costs.
Regarding font installation. The current fonts are easy to install on Windows, Mac, and Linux. For iOS, a configuration profile is available that includes the 2 fonts. For all operating systems, a font-face declaration can be used to load the fonts in real-time. The fonts are about 10 MB in total, which is a big hit, but they only need to be loaded once.
Android can not install the fonts, so the font-face declaration must be used. Android will only support script that are fully in Unicode, so it is possible that Android will natively support SignWriting in the future if the 2-D font is created and the additional 17 characters are accepted into Unicode. -Slevinski (talk) 15:31, 16 March 2017 (UTC)
"exagerated" → "exaggerated"
"moves in a large, exagerated path" should be "moves in a large, exaggerated path". Do we really need to vote on such a change? --Mortense (talk) 16:05, 29 March 2017 (UTC)
Fixed! --Daniel Carrero (talk) 16:08, 29 March 2017 (UTC)
