This would have been another great proposal for the "Multilingualism" main topic.

Adding it to "beyond wikitext" for now. I'd like to see a little bit more development of the proposal though -- vertical writing support already exists in the incubator, and this topic was discussed on the mailing list in May/June, starting at https://lists.wikimedia.org/pipermail/langcom/2016-May/000622.html.

We could use a precise bulleted list of what needs to be done, and what the desired outcomes of this session are. Why isn't the support currently running in the incubator enough?

Vertical writing support is only a proof of concept on Incubator. Thanks for the link to the mailing list discussion. I look forward to reading it.

Unfortunately, I will not be able to attend the developer summit in real life, although I will keep an eye on the possibilities of online participation.

As far as a precise bullet list of what needs done, that is a great idea. I will see what I can do and invite anyone else to contribute their expertise and knowledge.

Regarding the support for vertical writing mode on incubator, I believe it is limited and only supports a fraction of the CSS that would be needed in a top level Wikipedia. For the ASL Wikipedia, we are looking forward to moving to ase.wikipedia.org someday after we have enough content and activity. So while supporting vertical writing mode on Incubator is possible, I do not think we have fully defined what is required to move into production. So in part, this activity is to remove one of the roadblocks for the various sign language Wikipedia project to move from Incubator to production. In addition to American Sign Language, there is interest from Tunisian Sign Language, Brazilian Sign Language, Portuguese Sign Language, Russian Sign Language, and several others.

Who would be the person facilitating this session? Please assign this task to that person if you are aiming to have this session pre-scheduled. Thank you!

@Slevinski if you will not be attending the dev summit, we will need to identify a champion who could present this, either as a pre-scheduled session or as an unconference topic. I think the goal should be to develop that "precise bullet list of what needs to be done" -- although we can also do that online, in this phab task. We don't need to wait until the dev summit!

I guess it is hard for an outsider to understand from this task or the linked resources of the current status. So I would echo on having a summary on current status in addition to what needs to be done.

For example, I was looking whether these are already in Unicode, or trying to get into there.

@Nikerabbit Can you list what other information you would like in a summary about this task? For the current status of the ASL Wikipedia, we are moving forward on Incubator with 58 articles and growing. For the current status of supporting vertical writing mode in MediaWiki, there is basic support available on Incubator and some discussion available in the linked resources.

Vertical Writing Mode is W3C. Unicode is not directly related to this task. All of the work on the ASL Wikipedia on Incubator is UTF-8 compatible.

Regarding Unicode, part of the SignWriting script was added to Unicode version 8 without the approval of the SignWriting community. There are 3 issues that make it unusable. These issues have been reported to the UTC. (Issues with SignWriting in Unicode 8)

The main specification of Formal SignWriting is covered in an Internet Draft submitted to the IETF. (draft-slevinski-formal-signwriting) Formal SignWriting has been stable for 4 years and will hopefully be published as an RFC once the editorial issues have been addressed.

I do have some doubts on this approach. UTF-8 compatible is not the same thing as being in the Unicode. Any post-processing step – something what by my understand is currently used – will make it a lot more difficult to support properly. E.g.. there is flash of unstyled text, what if JavaScript is not available and so on.

But there seems to be some issues that are orthogonal to the script issue, such as producing the top-to-bottom layout using CSS. It would be good to introduce the concept of flipping or rewriting CSS styles on the fly to alter the layout and what problems you are currently experiencing there. Also, is there something else that needs solving?

The transformation from ASCII to SVG can be done on the client-side or the server-side. Client-side is easier and smaller. Server-side doesn't require JavaScript, but requires a plugin with a security review. Either client-side or server-side, this approach isn't the perfect solution, but it is currently the only solution that actually works.

Full Unicode requires 2 parts: a font and approved characters. For the font, there is a prototype font that can handle the 2D layout, but it requires Graphite, only works in Firefox, and isn't production ready. For the future, a new 2D font is planned, created with Volt, that targets MS's Universal Shaping Engine, but this font will start as MS only. There is hope that aspects of the Universal Shaping Engine may be supported by other operating systems. Regarding the approved characters, the current characters are insufficient to support the SignWriting script and the characters are unusable. If the new 2D font works and we are able to gain the approval of a UTC voting member, there is hope that SignWriting can be full Unicode, but this not guaranteed. Work on the new 2D font is planned for next year and I will be attending another UTC meeting in a few years from now.

Regardless of what happens with Unicode, any work done on the topic of Vertical Writing Mode will be useful with and without full Unicode.

@Slevinski, are you planning to attempt the dev summit? This seems like a worthwhile unconference session, but it would need a session leader.

@cscott, unfortunately, I will not be able to attend. I created this activity as part of the scholarship application, but I was declined.

Is @Slevinski will not be attending the summit, is there anyone who would be interested in facilitating this session?

To maintain the consistency, please consider referring to the template of the following task description: https://phabricator.wikimedia.org/T149564.

In T149056#2823541, @Nikerabbit wrote:

I do have some doubts on this approach. UTF-8 compatible is not the same thing as being in the Unicode. Any post-processing step – something what by my understand is currently used – will make it a lot more difficult to support properly. E.g.. there is flash of unstyled text, what if JavaScript is not available and so on.

@Nikerabbit, thanks for this comment. Recently, I've reconsidered the characters needed for Sutton SignWriting. If I use the 672 characters already accepted into Unicode, I can complete the script encoding with an additional 17 control characters. The content of the ASL Wikipedia could be converted from the lite ASCII markup (known as Formal SignWriting) into a pure Unicode stream. This approach would require development of a 2-D font which could be built on top of the current fonts, but this approach wouldn't require any extra post-processing step for display.

I have created a Wikimedia grant proposal for the font development. I would appreciate any comments or endorsements on the project grant page. With a working 2-D font, I can officially propose the 17 additional characters for inclusion into the Unicode standard.

@Slevinski: Did this session take place?
If yes, are there any notes or action items to share? Are there any actionable items (tasks to create / link?) from this session?
If not, could you close this task as declined? Thanks in advance!