User:Slevinski/SignWriting/Tech

From Wikimedia Incubator

above template based on Meta:Tech.

SignWriting Gadget[edit | edit source]

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.
  • (Code for the proposed changes is here.)

Some other things:

  • 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]
    Started work on mutationobserver. --Yair rand (talk) 20:33, 30 July 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.

--Yair rand (talk) 10:27, 2 June 2013 (UTC)[reply]

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.
-Slevinski (talk) 14:59, 3 June 2013 (UTC)[reply]
  • 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]
  • When the gadget is used on mobile, it brings up a "TypeError: Cannot call method 'toString' of undefined". This could probably be fixed by making this change. --Yair rand (talk) 18:21, 3 June 2013 (UTC)[reply]
  • How did you enable the gadget for mobile? I couldn't figure it out. MF-Warburg had trouble too. Thanks for all the help. -Slevinski (talk) 21:13, 4 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]

AS1f550S22a04S15210S20500M541x574S20500492x552S2ff00482x483S22a04515x522S15210504x543S1f550517x502 AS10003S1dc0aR525x524S1dc0a482x500S10003492x476S20500515x504S20500476x488 R541x518S1500a459x490S2ff00482x483S15002510x489S21900520x480S21900465x481

  • 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.
    What exactly is the extra text supposed to do? Should it be ignored by the JS for purposes of generating the DOM? --Yair rand (talk) 22:31, 30 October 2013 (UTC)[reply]
    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]
    Not quite right. When the text wraps, each line of a paragraph needs a vertical bar as well. Here's a nice illustration that includes the vertical bars. -Slevinski (talk) 19:48, 6 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]
    That should work nicely. /S38[7-9ab][0-5][0-9a-f][0-9]{3}x[0-9]{3}/ is correct for punctuation. Slevinski (talk) 14:38, 8 November 2013 (UTC)[reply]
    Done. --Yair rand (talk) 22:37, 10 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:

L592x606S18d20408x394S1f720408x424S20320484x484S1fb20484x568S11a20413x443S11502469x591S19220413x477S14720484x522S1f720479x503S14a20484x405S1dc20475x425S19220484x460S14a20413x501S16d20570x405S1f720566x430S11920565x452S10120571x483S19a20564x516S14a20484x548

  • 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]
    Just tested inserting a stretched line break. Looks pretty awful, tbh. :( I'll try to think of some other alternative. --Yair rand (talk) 10:06, 3 December 2013 (UTC)[reply]
    Thanks for looking into the issues required to fully support the grammar of written sign languages. -Slevinski (talk) 19:04, 6 December 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.
  • Code is at User:Yair rand/signwriting viewer.js. This sound feasible/positives outweigh the negatives? --Yair rand (talk) 08:10, 14 July 2014 (UTC)[reply]
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]

Browser Support[edit | edit source]

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.

Firefox[edit | edit source]

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]

Chrome[edit | edit source]

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.

Chrome and other Webkit browsers do not handle anchors correctly. --Yair rand (talk) 01:50, 22 October 2013 (UTC)[reply]
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]
Fixed it. Not exactly an elegant solution, but it seems to work. --Yair rand (talk) 05:10, 28 October 2013 (UTC)[reply]

Opera[edit | edit source]

Opera 15+ has the same level of support as Chrome has. Earlier Opera versions function like FF, but have many more bugs. --Yair rand (talk) 21:12, 20 October 2013 (UTC)[reply]

Internet Explorer[edit | edit source]

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]

Transparent PNGs are possible. Set the back=-1 in the query string. Here is an example. Slevinski (talk) 00:03, 21 October 2013 (UTC)[reply]
Hm, there seems to be a bug that causes the symbol to be outlined in pink whenever a non-integer size is used together with back=-1. Example.
I assume this is caused by the GD graphics library installed on the Wikimedia Labs server, specifically Nova_Resource:I-0000070c. The same example works on the SignBank.org example and the SignPuddle.com example. Is this worth investigating? Slevinski (talk) 15:11, 21 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[edit | edit source]

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]


Test Article[edit | edit source]

A large test article has been started. Excellent scroll to the right with text re-flow in Chrome. (resize the window and watch the signs flow.) It takes a while to load. Wp/ase/M535x550S14c02466x520S20500484x539S26507500x512S1ea50507x490S2ef01517x470S26500516x450

Slevinski (talk) 15:17, 19 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]

Caching Options[edit | edit source]

Three layers of caching have been added to the SignWriting Icon Server;

1) Modify Headers[edit | edit source]

The PNG and SVG files now include headers for caching. They are created with PHP. The following code has been added to each file.

 $expires = 60*60*24*365;
 header("Pragma: public");
 header("Cache-Control: maxage=".$expires);
 header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');
 header('Last-Modified: ' . $lastmod);
 header("Etag: $etag");

2) Check Headers and Not Modified[edit | edit source]

Etags and Last-Modified are checked to return 304 Not Modified response.

 if (@strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) == $lastmod ||
   trim($_SERVER['HTTP_IF_NONE_MATCH']) == $etag) {
   header("HTTP/1.1 304 Not Modified");
   exit;
 }


3) Create Sign Glyphograms Once[edit | edit source]

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.

In depth server caching reports are available:


not implemented[edit | edit source]

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.

Current use:

  • http://swis.wmflabs.org/glyphogram.php?font=svg&text={FSW String}&line=333333&fill=ffffff&size=1.55

Possible change:

  • http://swis.wmflabs.org/img/svg/1.55/333333/ffffff/{FSW String}.svg


Slevinski (talk) 14:58, 15 January 2014 (UTC)[reply]

Page Titles[edit | edit source]

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.

Expanding Text for Sorting[edit | edit source]

Page titles need to sort. Sorting is explained in Sutton's SignSpelling Guidelines. The mathematics of sorting is covered in MSW: Sorting Terminology.

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.

Shortening Text to Fit[edit | edit source]

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.

Bad title[edit | edit source]

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]]

Slevinski (talk) 14:19, 31 October 2013 (UTC)[reply]

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]


Discussion page move[edit | edit source]

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]

Sounds reasonable. (I'd recommend using the normal Special:MovePage instead of simply copying the contents over, though, in order to preserve the page history.) --Yair rand (talk) 22:25, 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]

Unstyled SignWriting text[edit | edit source]

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.

--Yair rand (talk) 05:41, 18 November 2013 (UTC)[reply]

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.
-Slevinski (talk) 18:38, 23 November 2013 (UTC)[reply]

Sign name as a user name[edit | edit source]

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) M514x536S15a06487x464S10e20498x478S29b0b486x501[reply]

This technique will not work for the link to the user page, but it can be used on the user page. User:M514x536S15a06487x464S10e20498x478S29b0b486x501