Latest comment: 10 years ago56 comments2 people in discussion
The new SignWriting gadget looks great. Having the text at font-size: 0% is an excellent solution to the problem of not being able to copy text. A few issues, though:
Instead of applying identical inline styles to every signwriting div, I think it would be preferable to just set a standard CSS class for them, and apply the styles to the class.
The fact that hovering over a signwriting link has no effect on the text is a bit jarring, but the writing system doesn't really lend itself to having underlines. Perhaps adding something like opacity: 0.8 to hovered links would help.
The size of the text is a bit large. I think that shrinking it somewhat might be an improvement. (I can't actually read any of the text, though, so my opinion on the sizing doesn't mean all that much.)
Using innerHTML all over the place to change tho DOM is probably considered bad practice, and it comes near causing XSS vectors in a few places. Using normal dom methods would probably be preferable.
Currently, 70% of visitors to Wikimedia sites use browsers that support writing-mode for vertical text. This might not be considered high enough to start using most features, but having a vertical text wiki without using writing-mode seems effectively impossible, so this is probably not a normal case...
Long-term, ResourceLoader needs to be modified to support ttb wikis, switching top with left, right with bottom, and height with width, much like it does with rtl wikis in switching right and left. Shorter-term, perhaps a script could crawl through the stylesheets on the page and make the appropriate changes.
The server serving the SW images does not support using secure server, and using the non-secure server results in warnings or errors when used together with the Wikimedia secure server.
Are the varying left-margins on the SW text necessary? I know pretty much nothing about SignWriting, but if the left margins aren't necessary, it will probably make things a lot easier...
There are some things that the gadget won't really work for (at least right now), such as dynamically generated text. For example, in the "Contents" box, clicking "hide" will change the text to "show". With SignWriting, clicking on it would change the legible SW text into "M 521x531S10012491x516S15a18479x503S26620486x469".
I suppose it could just have a mutationobserver check everything, but that probably would have significant performance impact. var MO = window.MutationObserver || window.WebKitMutationObserver; MO && (new MO(function(mutations) { mutations.forEach(function(mutation) { f(mutation.target); }); }).observe(document.body, { subtree: true, characterData: true })); --Yair rand (talk) 14:10, 3 June 2013 (UTC)Reply
Another issue that needs to be addressed is tooltips. As far as I know, there is no way of assigning HTML to the "title" attribute, which means that a separate script will need to be used to emulate the normal title behavior.
Similar issue: <select> tags <input> tags won't allow HTML inside. Not sure what the solution to that would be.
Thanks for the edits to the script. Very nice. I merged your changes with minor modification.
Regarding the other issues...
I will continue to look into writing modes.
Secure serving for the SignWriting SVG images? I'll have to investigate and maybe rebuild the Lab server.
Left margins are essential.
For dynamically generated text, the signwriting_styled function should be called with the modified node as input. Knowing when to call the function is the difficult part.
There are issues with tooltips, select, input, and the like. Work in progress.
Another issue: The SignWriting text, being technically images, does not turn the cursor into a "text" cursor when hovered over. This could be solved with the following CSS: .signwritingtext{cursor:vertical-text;}a .signwritingtext{cursor:inherit;} --Yair rand (talk) 17:00, 3 June 2013 (UTC)Reply
Oh, I didn't actually enable the gadget for mobile, I just tested the code by using the JS console. I know that js can be added to the mobile site through Mediawiki:Mobile.js, but I don't know much about setting gadgets up for mobile. If the gadget isn't working with ResourceLoader, as MF-W said, I suspect that it might be because the script doesn't specifically delay running until after onDOMReady (by wrapping the signwriting_styled() in $(document).ready or similar). --Yair rand (talk) 22:05, 4 June 2013 (UTC)Reply
Whatever SW input system is planned should probably be integrated into ULS's Input Method Editor at some point, if possible. At some point, Wikimedia users might have usernames in SignWriting, and will need to be able to log in with them even if they're not on a sign language Wikipedia. Also, Wikidata will need ways of easily adding interwikis to sign language Wikipedias. Anywhere that needs general multilanguage text input help should also support SignWriting.
ASL numbers are not, as far as I know, one of the available predefined ordered list types in CSS. Once @counter-style is available something like this could be done, but are there any solutions for what to do for ordered lists until then? --Yair rand (talk) 15:23, 4 June 2013 (UTC)Reply
The current method of searching through all of a textnode's ancestors for each node individually to find the background is quite inefficient. Doing something like this would be more efficient, I think. --Yair rand (talk) 01:12, 11 June 2013 (UTC)Reply
Are the left margins always essential, even for, say, the "Page"/"Talk"/"Edit"/etc tabs? If so, that will cause the interface to be quite bulky... --Yair rand (talk) 22:22, 30 June 2013 (UTC)Reply
Hmmm, does it need to be obvious where the margin starts? If the page were to look like this, would the positioning of the signs in the left bar be problematic? --Yair rand (talk) 20:33, 30 July 2013 (UTC)Reply
Should the articles from the labs site be imported here? I don't think that Special:Import supports importing from labs sites, but I think the attribution requirement can be filled by listing and linking the contributor names from the edit summary. --Yair rand (talk) 22:22, 30 June 2013 (UTC)Reply
Signwriting images don't tend to handle highlighting in the way that normal text does, so I've started work on a system to have them more accurately highlight like regular text (changing images, fixing selection positions, etc). --Yair rand (talk) 09:37, 26 August 2013 (UTC)Reply
One issue I've noticed with this is that the images have a large flicker problem, even when going back and forth between highlighted and unhighlighted. It appears that the images aren't being cached at all, so they need to be reloaded every time. Is this fixable? --Yair rand (talk) 13:10, 2 September 2013 (UTC)Reply
The images are not currently cached on the server. I'm not sure the best way to create the cache. I need to take some time to investigate the options. It's great that you are looking into the highlighting issue. I had a prototype for highlighting, but it wasn't consistent across the browsers. Slevinski (talk) 19:53, 11 September 2013 (UTC)Reply
That would be because of the AS10003S1dc0a at the beginning of the sign. Since "R" is no longer the first character in the text, the sign isn't pushed to the right.
If I've understood the issue correctly and the R/L checking is supposed to ignore the AS## bits at the beginning, the issue is now fixed in the version in my userspace. --Yair rand (talk) 05:01, 31 October 2013 (UTC)Reply
You have understood correctly. The AS## bits are used for sorting and normally invisible. They should be included in text but not visible in the DOM. I applied your update and the issue is fixed some of the time. The example above is still a problem. On the All pages in this wiki, the page title from above appears incorrectly in the link, but correctly in the tool tip. I've seen the problem fixed while editing pages, but not always. Slevinski (talk) 14:55, 31 October 2013 (UTC)Reply
What is the best way to add a vertical bar between the lines of paragraph text? The vertical text wraps very nicely, but the columns are too close to clearly distinguish. Writing in lanes (left or right) can interfere with reading flow and causes confusion. Vertical bars between the text lines are needed. This option isn't supported in CSS unfortunately. There is a first-line pseudo element, but not an every-line option. There is a line-height property that we may need to increase. I did find an image placement hack for a vertical bar between reflowing text, but I couldn't find an elegant solution. Any ideas? Slevinski (talk) 15:00, 5 November 2013 (UTC)Reply
Left borders on the .signwritingtext elements could work, I suppose, though it looks a bit odd directly "underneath" (rightwards of) headers, as well as on elements like the "Contents" label in the table of contents. --Yair rand (talk) 21:32, 5 November 2013 (UTC)Reply
Hm? That seems to be the way it's functioning currently, at least on Chrome and Safari. (IE had a bug with vertical align, which I've just fixed.) --Yair rand (talk) 07:04, 7 November 2013 (UTC)Reply
Yes, I see it now. Thanks. Might have been a refresh problem. I think this will work. Any way to make incomplete lines continue to the end? -Slevinski (talk) 18:19, 7 November 2013 (UTC)Reply
It would be possible, using some absolute positioning and the :before pseudo elements, but I'd recommend against it. Guaranteeing full-height bars means that they'll jut out of simple boxes, slice through floating images or other elements, and thoroughly mess up any moderately complex layouts (charts, floats, and so on). --Yair rand (talk) 23:55, 7 November 2013 (UTC)Reply
A small matter, but might be worth addressing if it's solvable. In thoery, line breaks should not occur before punctuation. Unless it's the first symbol to be written in a paragraph, punctuation should never start a new column. This issue can be seen on Incubator at the end of any paragraph. Resizing the viewport, it is possible to position the final punctuation of any paragraph so that it is the only symbol in the last column of that paragraph. This shouldn't be allowed. Any way to fix it? -Slevinski (talk) 18:30, 7 November 2013 (UTC)Reply
So, when it doesn't fit on the line, the previous element should come with it to the next line? One fairly simple way to do this would be to wrap any punctuation together with its preceding element in a white-space: nowrap; span. Which symbols count as "punctuation"? All that have the /S38[7-9ab][0-5][0-9a-f][0-9]{3}x[0-9]{3}/ format? --Yair rand (talk) 23:55, 7 November 2013 (UTC)Reply
Bug 56920 is causing wgPageContentLanguage to return an incorrect value, causing the gadget not to recognize pages as being in sign language. Added a fix to User:Yair rand/signwriting viewer.js. (Also, a bunch of performance boosts, plus having the script notice a bunch of non-ASL sign languages. A full list of ISO codes of sign languages would probably be helpful for this.) --Yair rand (talk) 23:42, 14 November 2013 (UTC)Reply
It was reported that sometimes the left side of signs in the left lane can be cut off. The user reported this as a "minor detail". The scope of the problem and browsers involved has not yet been analyzed. Slevinski (talk) 15:04, 23 November 2013 (UTC)Reply
Hm, it looks like this is a pretty serious issue, actually. In all signs where x1 < 390 - ( ( o[k] || 0 ) * 75 ) (that coming out to x1 < 465 in left-lane signs), all the excess gets cut off. In most existing cases, this is only a few pixels, which could be fixed if the left boundary were just moved a rather inconsequential amount (say, 5-10). An example of a more extreme case: the spelling of "Marie-Élisabeth Candy" in this article, the entire leftmost name gets cut off:
I can't think of any simple solution to this. Is there any lower bound of where putting signs works? Stretching out the left edge of every single block to accommodate every sized box possible would add hundreds of pixels of empty extra width to every column. JS checks can easily detect a leftward overflow, but I can't think of anything that could be done to the specific problematic signs that could be helpful. Repositioning them to the left to overlap with the previous line would be problematic by itself. Maybe an extra-large line break could be pushed in before each instance of a sign like this, together with negative left-positioning of the bulky sign onto the empty space? That sounds like it could result in its own problems. Quite the puzzle. --Yair rand (talk) 05:47, 25 November 2013 (UTC)Reply
If JS can detect the overflow, the line-height of the paragraph (or other element) should be adjusted if possible. This will result in wasted space for the paragraph in question, but it will not effect other paragraphs at least. I like the idea of the line break, but text reflow complicates the issue. -Slevinski (talk) 21:05, 26 November 2013 (UTC)Reply
Changing the line-height CSS property (I assume that's what you're referring to?) wouldn't actually increase the gap between the baseline and the text, actually. The most it could do would be to increase the effective right margin of the line. Enlarging the space between the signs and the bar could only be done, as far as I can tell, by modifying the padding-left or the width of the elements. This would come with some complications, such as having to also modify elements coming after the too-wide box, both spatially and chronologically (via mutationobservers, when the occasion arises), which could be very difficult. Perhaps simply pressing the symbols to the left edge of what's available would be an option? I'm not sure how much spatial information would be lost in these cases, nor how important exactness of the positioning is. --Yair rand (talk) 05:48, 27 November 2013 (UTC)Reply
Using negative left margins can move the rest of the line enough to the right to have things look right, but then it can overlap with the following line, unfortunately. Max-height invisible floats with the appropriate amount of width could push the next line a bit, but any complex layouts would interfere with it, and such floats have a tendency to go all over the place with inconsistent behavior. --Yair rand (talk) 08:14, 12 December 2013 (UTC)Reply
Another possible option: The signs that go too far to the left could be shrunk enough so that they don't cause problems. This doesn't really work all that well; many of the signs need to be shrunk so much that they can end up illegible. --Yair rand (talk) 21:34, 15 December 2013 (UTC)Reply
@Slevinski: Okay, I think I have a (sort of) solution. Changing the vertical-align back to middle allows positive margins on either side to both move the image relative to the center while increasing the width of the line overall. So, if a sign needs to be moved to the left by 50px, 100px can be added to margin-right, making the new center of the box 50px to the right of the old center, bringing the left edge to the right location. The margins can also be used to "balance" the sign so that each left border (the vertical bar between each line) still gets lined up with the others. Some downsides:
Signs that extend a lot to the right (x2 > 540 currently) add equivalent margins on the left side of the line, to the left of the border, occasionally resulting in a lot of unnecessary whitespace.
The bar itself won't move to accommodate the signs that extend too far to the left. The signs will go to their appropriate positions relative to the middle of the column, and the part of the bar where it's "breached" by the sign is removed. Since the margins are all positive, there's no risk of it overlapping with another line, but it could still cause some confusion for the bar not to be a clear divider in those spaces.
There's an annoying little bug that causes the bar to be occasionally off by one pixel, probably due to rounding the dimensions. Still can't figure out how to fix that.
It seems Chrome (on Mac) has changed and no longer switches to vertical writing mode. So both Firefox and Chrome flow to the bottom of the page in a single long line. Safari still does the switch to vertical writing mode and scrolls to the right. FYI. -Slevinski (talk) 13:05, 14 July 2014 (UTC)Reply
That's unfortunate. I'm not sure what versions/situations that applies to, though. Vertical writing mode is working fine on Chrome on Windows (both current build and Canary). Googling around hasn't brought up anything about any Mac-specific Chrome regressions in writing modes, and browsershots is showing the pages to work fine on Chrome 35.0.1916.47 / Mac OS X 10.8. Quite confusing. --Yair rand (talk) 18:21, 14 July 2014 (UTC)Reply
Latest comment: 11 years ago16 comments2 people in discussion
The ASL Wikipedia on Incubator works to various degrees depending on the browser. They operate differently, so use whichever is appropriate on your platform.
The ASL User Interface is not available in the Universal Language Selector yet.
The Translate Wiki effort continues and the option will hopefully be available soon.
The Firefox browser uses a single column downward flow and does not update the user interface.
If we're considering Firefox to be a "supported" browser, that opens up some possibilities. Firefox is currently the only browser that supports appearance: tooltip;, allowing for an element to take on the appearance of a native tooltip, which I think would be preferable to the current look of the SW tooltips. (Implemented in the version in my userspace.) --Yair rand (talk) 21:12, 20 October 2013 (UTC)Reply
The Chrome browser uses the vertical text mode with a scrolls to the right.
Resizing the Chrome browser will demonstrate the text reflow ability of SignWriting Text.
In Chrome, the ASL user interface is manually applied to the page and overwrites whatever language was requested with the Universal Language Selector.
This defect is apparent when trying to use the table of contents. Clicking on a section title does not properly set the viewport on the horizontal axis according to the anchor location. This causes some confusion. Slevinski (talk) 14:16, 26 October 2013 (UTC)Reply
IE9+ seems to work well, albeit with the occasional bug in the tooltips. I just added basic support for IE8 (which supports vertical content) by using PNGs where necessary. (This would work better if the PNGs had transparent backgrounds. Would that be possible?) IE8 doesn't support MutationObservers or mutation events, so dynamic content won't work in that browser. --Yair rand (talk) 21:12, 20 October 2013 (UTC)Reply
FWIW, the Canvas in HTML5 can transform the SVG from the server into a PNG on the client side. The PNG font isn't as smooth and the SVG. Slevinski (talk) 15:11, 21 October 2013 (UTC)Reply
Creating a PNG from an SVG is available with the SignPuddle Customize feature. This example shows the SVG as size 7 with a JavaScript conversion to PNG. This pixelated example shows the PNG as size 7. I'm not sure about transparency of PNGs created with the canvas. Slevinski (talk) 15:52, 21 October 2013 (UTC)Reply
Well, on one hand, IE8 currently has a 10% global market share (though about half that on Wikimedia sites), which is quite significant. On the other hand, the non-transparent backgrounds aren't actually particularly noticeable, so I'm not sure how important it is. --Yair rand (talk) 00:41, 22 October 2013 (UTC)Reply
IE11 removed support for the Microsoft's document.selection, without adding support for some of the standard getSelection properties and methods. As a result, text highlighting currently does not work in that browser. --Yair rand (talk) 02:27, 30 October 2013 (UTC)Reply
Due to a bug in IE's offsetHeight/Width values when writing-modes are used, IE occasionally misplaces tooltips. The script relies on jQuery's width and height functions, and those should theoretically have a workaround for the IE bug (I think?), so I've filed a bug with jQuery. If it doesn't get fixed on that end, I'll modify the tooltip code to fix it, somehow. --Yair rand (talk) 07:43, 7 November 2013 (UTC)Reply
Safari works fairly well, but has some layout issues that the other Webkit browsers don't, such as mistaken line breaks being thrown in. --Yair rand (talk) 21:12, 20 October 2013 (UTC)Reply
Unrelated note: I've requested at MediaWiki talk:Gadgets-definition that the gadget setting be changed so that it loads in the head. Hopefully this will allow the stylesheet changes to take effect before the body loads, thus eliminating the re-shuffling of the whole body content towards vertical-text orientation. --Yair rand (talk) 02:48, 21 October 2013 (UTC)Reply
For a specific font, size, and color; the sign image does not change.
It is 3 times faster to read an archived file than to create the SVG file from scratch.
For PNG files, it is 15 times faster to read a file than to create the PNG.
The SignWriting Icon Server has been modified to allow server side caching.
Every image request is converted into a file name. If the file exists, it is served.
Otherwise, the file is created. The next time the image is requested, it will send the archived file.
The current image requests use a query string after the ( ? ) in the URL. It is possible to change this to a URL that does not use a query string. This has not been implemented.
Tests showed that caching was effective without moving the image attributes out of the query string and into the URL sub-directories.
Latest comment: 11 years ago2 comments2 people in discussion
Page titles are an issue for the SignWriting strings. Within MediaWiki software, page titles can only be 255 characters long. This limitation allows for 13 symbols to be used in a page title that sorts properly. Each additional symbol reduces the sorting accuracy. A page title with 19 symbols is the maximum possible and does not sort.
The name of a sign has 2 parts: an optional temporal prefix and a 2-dimensional arrangement. The temporal prefix is a linear list of symbols arranged according to timing and a theory of ordering. Valerie Sutton's theory is explained above. When the temporal prefix is included in the page titles, they sort automatically using a binary string comparision. Signs that do not include the temporal prefix do not sort properly.
The ordered list of symbols can be created with SignPuddle on entry titles using the SignSpelling command. A better solution to building the sorting prefix is coming soon.
Properly sorted page titles can only have 13 symbols. If at all possible, do not go above this count.
If a title must have more than 13 symbols, trimming part of the sorting prefix will make it possible to use extra symbols. Each additional symbol reduces the sorting accuracy. A page title with 19 symbols is the maximum possible and does not sort.
Names that are longer than 255 are not supported in MediaWiki software. Unfortunately, the Bad title page does not report that the page title is too long only that it might be "invalid, empty, or an incorrectly linked inter-language or inter-wiki title. It may contain one or more characters that cannot be used in titles." I would suggest a specific message regarding allowed length and the amount of overflow. Bugzilla?
Ignored in Markup
It is impossible to create a link when the page title is over 255 characters. Notice the brackets in the text below.
[[Wp/ase/AS1f550S22a04S15210S20500M541x574S20500492x552S2ff00482x483S22a04515x522S15210504x543S1f550517x502_AS10003S1dc0aR525x524S1dc0a482x500S10003492x476S20500515x504S20500476x488_R541x518S1500a459x490S2ff00482x483S15002510x489S21900520x480S21900465x481_M533x569S1f548478x520S1f540508x523S23100507x552S23110467x550S30e00482x483]]
It might be possible for the title size limit to be made configurable before the launch of the ASL WP, which would solve the issue altogether. I don't think there's a bug open for it yet, though. --Yair rand (talk) 00:28, 5 November 2013 (UTC)Reply
Latest comment: 11 years ago3 comments2 people in discussion
I would like to move this discussion to the general SignWriting Tech page. This discussion is about SignWriting in general rather than ASL specifically. This discussion page should be about the Main page of the ASL Wikipedia. Thoughts or opinions? Slevinski (talk) 21:43, 11 November 2013 (UTC)Reply
Okay, thanks for the advice. The page has been moved from Talk:Wp/ase redirected. I will rewrite the ASL talk page so that it links here. The ASL talk page should be a discussion about the Main page of the ASL Wikipedia instead of a general SignWriting tech discussion. Slevinski (talk) 15:14, 12 November 2013 (UTC)Reply
Latest comment: 10 years ago2 comments2 people in discussion
There are a few areas where unstyled text will still be visible to users:
Text in the <title> element, that is used in the browser's top bar and other places. There is no way to place images inside this element, so I don't think there's any way around this. If Mediawiki:Pagetitle were modified so that the "source" version of the page's title (M###...) were not in the title element at all, all page's would have the same title, which might itself be problematic.
Text in the address bar and similar. Completely unresolvable, I think, but not really significant.
The name of the language, when appearing in interwiki links from projects in non-signed languages, assuming the native language name is given as raw SW string. Most projects probably won't at any point have a signwriting gadget enabled (far too heavy, performance-wise, for not enough gain). All language names use the special "Autonym" webfont, loaded from the server, so if there's any way to have a webfont convert a specific string to a specific image, than that could be done for each sign language name, I suppose. Not an issue when interwikiing from one sign language wiki to another.
Usernames that use SW text, when appearing on non-sign language wikis through SUL: Example. Unlike the above case, these can't make use of a special font.
Since the gadget's signwriting_styled function is tied to $( document ).ready, there is a flicker of unstyled SW strings in between when the individual elements containing SW are loaded and when the full DOM finishes loading. One possible solution to this would be to tie the function into the onanimationstart hack to trigger the function on every new group of elements as they're loaded onto the page. Could be a bit performance-heavy, though.
For some of these situations, it is possible to view the SignWriting through a user script or a bookmarket.
For other wiki projects where the SignWriting Gadget is not enabled, a user script can be used that will display the SignWriting. Instructions are available on the English Wikipedia.
For general web sites, where raw Formal SignWriting strings are found, a bookmarklet can be used that will transform many of the visible FSW strings into SignWriting images.
Latest comment: 10 years ago1 comment1 person in discussion
It is possible to have a sign name as your user name using a Formal SignWriting string. Up to 3 symbols can be used, which results in a name that is 48 characters long. Probably too long to type from memory, but easy to copy and paste. For example, if Valerie Sutton ever wanted to log into Incubator with her sign name, should could Double-Click her sign name below and copy the FSW string using the menu option Edit >> Copy or use a Right-Click >> Copy. For log in, paste the FSW string into the log in page. -Slevinski (talk) 15:04, 23 November 2013 (UTC)
M514x536S15a06487x464S10e20498x478S29b0b486x501Reply
