Wiktionary talk:About sign languages

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
  1. through July 2008


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
  1. Usage Use or mention in permanently recorded media, conveying meaning, in at least three independent instances spanning at least a year.

Should that be

  1. Usage Use 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. 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:
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)
My understanding is basically the same as msh210's. I think [[Wiktionary:Criteria for inclusion#Conveying meaning]] 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[edit]

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)


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 BentB@BackFinger-PalmBack-BentB@CenterChesthigh-PalmBack C@Ulnar-PalmUp-C@CenterChesthigh-PalmUp 1@CenterChesthigh-TipFingerForward(How are you?):
  • Stokoe symbols: []A⊤*ɑ []Cɑ* ØG< — This transcription cannot be used for Wiktionary entry names for obvious reasons.
  • Stokoe English: 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: 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: 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[edit]

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 K@...Chesthigh Nod(the two of you/them). 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 FlatO@...-PalmUpTipFinger... RoundVert FlatO@...-PalmUpTipFinger..., 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[edit]

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:
  • 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.
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)
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., 1@Forehead-PalmForward(German, Germany) from German Sign Language is replacing the colorful-looking 5@RadialHand-PalmBack-5@CenterChesthigh-PalmBack Wiggle-Wiggle.) For "Mexico"/"Mexican", the new sign is V@Sfhead-PalmDown Twist V@NearSfhead-PalmForward. I think I've seen a couple of signs using the OpenM shape, including OpenM@Sfhead-FingerAcross OpenM@NearSfhead-FingerAcross(Marines) and OpenM@TipFinger-FingerAcross-OpenM@CenterChesthigh-FingerAcross OpenM@FromTipFinger-FingerAcross-OpenM@SideChesthigh-FingerAcross OpenM@FromTipFinger-FingerAcross-OpenM@SideTrunkhigh-FingerAcross(museum). I suspect several other signs use that shape, but I don't know. And for OpenN, I think it's used in H^o@NearFinger-OpenN@CenterChesthigh Contact H^op@NearTipFinger-OpenN@CenterChesthigh(leech, to mooch), 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 5@NearPalm-PalmForward-FlatB@CenterChesthigh-PalmForward RoundVert FlatO@Palm-TipAcross-FlatB@CenterChesthigh-PalmForward(magnet, to attract). My MAINSTREAM sign is 5@SideChesthigh-TipAcross-5@SideChesthigh-TipAcross RoundHoriz-RoundHoriz 5@Palm-PalmDownTipForward-5@DistalCenterChesthigh-PalmDownTipForward. For "master", I'd sign Claw5@Shoulder-PalmDown Contact(boss, captain) or OpenA@SideChesthigh OpenA@SideNeckhigh(chief), 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 OpenM@InsideChesthigh-PalmDown-OpenM@InsideChesthigh-PalmDown Accel OpenM@BackFinger-PalmAcross-OpenM@CenterChesthigh-PalmAcross(magnet, magnetic), and MAINSTREAM is 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[edit]

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 (talkcontribs).

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)

Category:ase:English derivationsCategory:ase:English initializations[edit]

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?[edit]

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 [[Wiktionary talk:About sign languages/Archive 1]].) 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)