User talk:Slevinski

From Wikimedia Incubator
Jump to: navigation, search

Hello Slevinski and Welcome to Wikimedia Incubator!

To get an overview about what we are, and how you can participate, you can take a look at Help or the answers on Frequently Asked Questions. If you have any further questions, you can ask them on the Incubator:Community Portal. If you haven't created a user page yet, please create one with for example Babel templates on it. You can select your interface language in your preferences. If you make articles, templates or categories, don't forget to add a prefix!

-- Welcoming Bot 19:23, 11 May 2012 (UTC)

Sign writing gadget[edit]

Hi Slevinski, I created a gadget for your sign writing script which simply imports your script (MediaWiki:Gadget-Signwriting.js), and enabled the gadget per default, to make it easier for users. Please tell me if/when you need any help with importing pages from the ASE labs wiki. Best regards --MF-W {a, b} 21:41, 26 May 2013 (UTC)

Hello. First of all - great gadget and big kudos for you for that! Now: From security reasons it is not possible to load gadgets from user space, so I copied your gadget code to the global space. Should you need to update it, please let me or any other admin know. Thank you. And once again - great work!
Danny B. 17:27, 27 January 2014 (UTC)

IDs in the Signwriting image files[edit]

I notice that the SignWriting images served by the server contain elements with IDs such as id="base", id="fill", id="index", etc. Do these IDs do anything? If not, would removing them substantially speed up the loading of the images? The load time for a page full of the images is quite large, and it might make sense to try to look for ways to speed up the load time. --Yair rand (talk) 17:36, 24 July 2013 (UTC)

Strictly speaking, the IDs are not needed and could be removed. It would save some bandwidth, maybe 10%.
Originally, the symbols were 10 times larger. When I initially compressed the symbols, I decided to leave in the IDs because they provided some information that might be valuable and I was happy with the initial reduction. Looking back on the symbols now, I think you are right that the IDs should have been removed. The additional reduction would be nice, but other priorities need to be handled first. Slevinski (talk) 18:49, 24 July 2013 (UTC)
The SignWriting images in SVG have been refactored and improved again. I removed the IDs, saving a bit of room. I replaced rectangles with paths in the SVG. I added semantic class names of sym-line and sym-fill. The ISWA 2010 Font Reference has the new version available as a data file or an SQLite database. -Slevinski (talk) 15:18, 26 August 2014 (UTC)

Deaf Wiki[edit]

hello, how are you??? I'm a Deaf sicilian and italian. Do are you Deaf??? --SurdusVII (talk) 18:21, 28 July 2013 (UTC)

Greetings SurdusVII. I am not Deaf. I've been using sign language since the birth of my first child. None of my children are deaf, but I used sign language because the eye & hand develop faster than the ear & mouth. My son knew about 40 signs before he could speak. Years later, my wife took a position where half of the staff was Deaf. She learned sign language through immersion. She introduced me to her coworkers. That's when I found out about SignWriting. Soon after, I tried to create a website using SignWriting, but the tools didn't exist. I created a simple tool to help my development that caught the attention of SignWriting's inventor, Valerie Sutton. A few month's later we started to collaborate and we've been working together ever since. I've had the privileged to work with people all over the world in dozens of sign languages. We continue to develop and improve. We've accomplished a lot, but there is still a long way to go. Slevinski (talk) 13:20, 29 July 2013 (UTC)
Do you think you could help him start a test-wiki in Italian Sign Language (LIS) at Wp/ise? PiRSquared17 (talk) 15:47, 29 July 2013 (UTC)
Working on the Wiki projects will be easier once the new editors are ready to use. For now, there are 167 signs in the Italian Sign Language dictionary in SignPuddle. The Formal SignWriting (FSW) strings can be copied from SignPuddle and pasted into the wiki. If anyone is interested, I'd be happy to help. I'm sure Adam Frost would be happy to help as well. Slevinski (talk) 13:59, 31 July 2013 (UTC)
Not related to the topic above, but is the code for the new editors public/editable? --Yair rand (talk) 02:32, 7 August 2013 (UTC)
The code for the new editors is not ready yet. When it is ready, it will be part of the open source project SignWriting Icon Server; available on GitHub.
FYI, I just installed the latest version of the SignWriting Icon Server on Wikimedia Labs, which has a searchable API for the entire SignPuddle Online corpus. For ASL/English, you can use this link. For Italian Sign Language/Italian, you can use this link. The searchable API is a crucial aspect of the new editors. Currently a development preview; I still need to put together a video explaining how everything fits together. -Slevinski (talk) 16:19, 7 August 2013 (UTC)
yes, PiRSquared17, for Wp/ise in Italian Sign Language but on writing on language originale Lingua dei Segni Italiana. I would like to work in this project Deaf Wiki. --SurdusVII (talk) 08:23, 10 August 2013 (UTC)

User:Yair rand/signwriting viewer.js deploy?[edit]

I've been adding a number of features to User:Yair rand/signwriting viewer.js over the past bunch of months, particularly for vertical text-supporting browsers. What do you think of copying the content over to the currently deployed gadget, User:Slevinski/signwriting viewer.js? (Since the gadget is in your user space, editing access is restricted to you and the Incubator administrators.)

The code is certainly far from bug-free, but I think it's important to have an actual ASL environment available at this point, even if it's not working perfectly. For browsers that don't support vertical text, it will function pretty much the same as the currently-deployed version, displaying the content in one column without any of the special vertical adaptions or ASL Mediawiki messages in the surroundings. Both the performance-heavy stuff and the layout-changing code won't run unless the user is either viewing an ASL page or has their language set to ASL, so as not to disturb the rest of the incubator. --Yair rand (talk) 01:01, 10 October 2013 (UTC)

Thanks Yair rand. Very nice changes. I've replace the gadget with your script. 01:44, 10 October 2013 (UTC)


This page contains at the end of one of the paragraphs the following text: M570x516S1dc50504x484S1dc58473x484S28612430x

The last bunch of characters don't get processed by the script, as they are missing three numbers that normally follow the "x". Is this a bug in the script, or was this just copied over incorrectly? If this is a bug, how is the script supposed to interpret the absence of those numbers? --Yair rand (talk) 06:31, 14 July 2014 (UTC)

This was copied incorrectly. If a string is malformed, it shouldn't be processed by the script. Slevinski (talk) 12:12, 14 July 2014 (UTC)

Bug in SWIS?[edit]

The SWIS seems to be outputting three "rub" symbols for S20f02, while the Signbank shows only two for that sequence. Given the pattern from the other symbols, it appears to be a bug in SWIS. --Yair rand (talk) 03:37, 31 July 2014 (UTC)

I checked and 2 vertical rubs are displayed in SWIS as expected. Can you provide a link to an example? If there is a problem I'd like to identify it and fix it asap. Thanks. Slevinski (talk) 04:09, 31 July 2014 (UTC)
Sorry, I meant the "brush" symbols:
I'm seeing three in this image. --Yair rand (talk) 13:44, 31 July 2014 (UTC)
Thanks. That is weird. I was able to view the problem, but I am currently on the road. I will investigate properly first thing next week. Slevinski (talk) 15:02, 31 July 2014 (UTC)
This bug has been fixed for the ISWA 2010 font reference, for the SWIS project on Github, and for SWIS on labs. The problem only appeared for symbol S20f02. I erased the cache on the labs server, but you'll need to force reload the page in the browser to reload the local cache. -Slevinski (talk) 21:34, 22 August 2014 (UTC)

Two things[edit]

  • Is there any way to retrieve from SWIS a simple image of a symbol, with the width and height fitted to the size of the symbol (with unspecified position)?
  • Is there any way to query the SWIS API using JS from outside the SWIS domain itself? When I try it from here I get a Access-Control-Allow-Origin error, and the documentation doesn't say anything about any kind of callback parameter.

--Yair rand (talk) 16:56, 19 August 2014 (UTC)

  • You don't need to do anything special on the client side. CORS need to be configured on the server only. Several project are distracting me from finishing SWAP. It should be ready soon. I'll have CORS figured out. The address will be . -Slevinski (talk) 13:54, 9 September 2014 (UTC)


For the SWIS API, it is entirely homemade to support my development and showcase searching. I will be replacing it with SWAP in the near future, explained below.

Regarding the Access-Control-Allow-Origin error, I am unsure what is going wrong. It is possible to fix the SWIS API, but I would rather improve the SWAP API and documentation.


The SignWriting Asset Provider is built on the SLIM Framework. It is currently installed on The opening page is an editor prototype. The API section currently supports sign images, symbol images, and a conversion from query string to regular expressions for searching. I will be moving it to in the near future. I will be adding the searching of spoken or sign language next in the development.

Query strings allow for fast searching using regular expressions. The query string for any sign is simple Q. The query string for any sign that can be sorted is simply QT. For all signs, we can search the visible symbols used. For sortable signs, we can search the temporal prefix.

Documentation is a work in progress. For the new SWAP API, the documentation for the symbols is available.

-Slevinski (talk) 18:31, 19 August 2014 (UTC)

Excellent. By the way, I've been working on my own (keyboard-based) SignWriting input system for the past several weeks, which uses a few new ideas that I don't think have been tried before. I figure it couldn't hurt to have another alternative input system available, or at least add a few things to the ecosystem of ideas on how SW input systems should work. I'll probably post to the SW list about it in a week or so, once I get it at least somewhat usable.
Is there an existing "Generic autocomplete" tool/API available? That is, something that could take just a sequence of FSW and guess which parts are or aren't deliberately specific and then output a bunch of similar signs in a sign language? --Yair rand (talk) 01:07, 21 August 2014 (UTC)
I love keyboarding. I hope your ideas work out. Please share on the SignWriting List. If you like planning ahead, please consider presenting at the next SignWriting Symposium 2015 in July. For the 2014 symposium, I presented about the work on Incubator. I thanked you during the presentation.
A generic autocomplete tool/API is not quite available, but easy to build. I propose that we preload the ASL Wiktionary with data from SignPuddle Online. For the autocomplete tool, we use Wiktionary as the source. As we improve the Wiktionary, we improve the auto-complete. This design should scale as well. There may be a problem for signs with very long names.
To build a generic autocomplete tool/API, we need to leverage the FSW query strings. The FSW query strings allow for a wide range of searching options with quick results. The query string is used to create one or more regular expressions. The regular expressions are used to search the text file or database.
There are several productive searching strategies. The query string is defined in draft-slevinski-signwriting-text-03 section 3.2. First, any Formal SignWriting string can automatically be converted into several types of query strings.
  • Approximate spatial match - find any sign that uses a certain set of exact symbols in an approximate arrangement.
  • Exact symbol match - find any sign that uses a certain set of exact symbols.
  • Approximate symbol match - find any sign that uses a certain set of general symbols.
  • Hand & Movement simplification - For searching, the most important symbols are in category 1 and 2. To simplify before searching, drop all symbols category 3 and above.
SWAP for query transformation; Wiktionary for search content. Any sign language could leverage their Wiktionary and standardize their language.
I am currently packaging an early version of SWAP. I will make sure to document the existing API and expand it over time.
-Slevinski (talk) 18:47, 21 August 2014 (UTC)
  • Is SWAP going to support a size parameter? SWIS's only seems to work for pngs. --Yair rand (talk) 17:38, 6 October 2014 (UTC)
SWIS does not resize symbol SVGs. There is a reason, but I can't remember it right now.
SWAP supports sizing in the URL. Until I have the Github repo up and running, I have some information available on my main Github page.
All symbols and signs have a default size of 1. The size can be written directly in the URL. The precision is 2 or 3 decimal places.
Alternately, a viewBox can be set with an "x" in the url rather than the size. This feature will resize the symbol to the size of the container.
I am currently engrossed in the TTF font development trying to improve the font quality. I am hoping the TTF clarity will match the SVG, but I'm having a few issues with FontForge import and the way the SVGs were created. I'm working with inkscape and potrace to try to correct the issues. The TTF will allow for pages that are 30 times smaller than the SVG. One nice feature is that the font works with the symbol keys in plain ASCII as well as Unicode 8.
You'll need the fonts installed to view the second 2 columns, but the fonts aren't production ready.
After the TTF files are as complete as possible, I will complete work on the first SWAP release and install it on Wikimedia Labs.
-Slevinski (talk) 19:24, 6 October 2014 (UTC)

Two more buggy symbols[edit]

The symbols S27515 and S27513 appear somewhat distorted when pulled from SWIS: M561x514S27513443x485S27515542x485 --Yair rand (talk) 10:29, 29 September 2014 (UTC)

Thanks Yair and curses! Those symbols are wrong in the SVG refinement. You can see how they are supposed to look in the PNG version or the SVG smooth. I reviewed the SVG refinement closely and cleaned up a lot of issues, but I guess a few details still slipped through. I am currently working on the TrueType font development and I have the build script nearly completed. I am writing test/demo pages now. As I review the newly created font, I will also verify there are no more issues with the SVG refinement. -Slevinski (talk) 18:29, 30 September 2014 (UTC)
Excellent. Have you figured out a good way to prevent the symbols from interfering with copying/pasting? Shadow DOM isn't supported on all browsers, input elements mess with dragging, and the alt attribute doesn't have a consistent display (besides showing up in copies in some browsers anyway), so those wouldn't work. CSS Generated Content might be a viable option. .signwriting-symbol::before { content: attr( data-symbol ); } and such. Not sure about the performance impact, though.
Also, will bolding and italics work? Italics could be problematic, as it might skew the positions of certain parts of symbols relative to each other. --Yair rand (talk) 17:23, 1 October 2014 (UTC)

The issue with symbol S27513 and S27515 can be seen on the new demo pages. It goes back to a flaw in the original PNG. The image was corrected in the SVG refinement, but the size is based on the original PNG. That causes the skewing.

Italics and bold are possible if we want. I have 2 possible candidates in the SVG angular and SVG smooth. It is possible to support italics and bold in SWAP and with the TrueType fonts.

For copying and pasting individual symbols, with the new font, the symbol key can be used directly. If we set the font family in CSS, we can see the symbol image and use copy and paste directly with the symbol keys.

For SVG, the possible CSS integrations need to be explored and documented for the various systems. -Slevinski (talk) 19:24, 6 October 2014 (UTC)

SignWriting Truetype Webfonts[edit]

Are the SignWriting Truetype fonts available as Webfonts? I'm trying to speed up the SignWriting keyboard script, and most of the slowness is caused by needing to retrieve each image from SWIS. However, requiring manual download of each font probably isn't the most user-friendly. --Yair rand (talk) 12:52, 26 November 2014 (UTC)

Possible bug: Is S165 backwards?[edit]

The handshape with the symbol key 165, titled "Flat Split Baby", seems to have the finger pointing out where the index finger would be. Is this a bug of some sort, or am I just misunderstanding the handshape?

Also, the rotated versions of the symbol seems somewhat distorted: M572x515S16529442x485S16523542x485 --Yair rand (talk) 04:35, 8 January 2015 (UTC)

Written ASL Wikibook[edit]

Hi! Based off of your involvement with the ASL wikipedia, I was hoping you might be interested in contributing to the wikibook on ASL Writing.[1] I'm hoping more people will be able to contribute if they can learn how to use SignWriting, but resources are a little scattered right now, with makes it somewhat hard to learn at this point. If we had a wikibook that taught people how to use it, we might get a lot more contributors to the ASL wikipedia project. :)

LeptonMadness (talk) 18:06, 24 April 2016 (UTC)

Wiktionary work on ASL[edit]

Hi, Steven. User:Positivesigner brought my attention to the work you are doing on English Wiktionary, too. So without overriding the possibility of a true Wt/ase project here, I added a cross-wiki link to wikt:Category:American Sign Language on that root page. I hope that's acceptable to you. StevenJ81 (talk) 22:07, 13 February 2017 (UTC)

StevenJ81 - Sure, that's fine. We will be loading the ASL Wiktionary with the contents of the ASL Dictionary on SignPuddle in the future, but we're currently focusing on the ASL Wikipedia and other in-house projects. -Slevinski (talk) 22:20, 13 February 2017 (UTC)