Unicode: Difference between revisions

257 bytes added ,  2 months ago
no edit summary
No edit summary
Line 12:
 
==Proposals==
There are have been a few past proposals for the {{tp|sitelen pona}} Unicode block. In 2021, shortly after the publishing of the {{lipu ku|en}}, Gabriel Tellez submitted a proposal, consisting only of the glyph chart for {{tp|[[linja pona]]}}.<ref>{{cite web|url=https://www.unicode.org/L2/L2021/21137-toki-pona.pdf|title=Toki Pona for Unicode|website=The Unicode Consortium|author=Gabriel Tellez|date=2021|access-date=2024-01-29}}</ref> It was rejected by the {{w|Script Ad Hoc Group}} in its recommendation.<ref>{{cite web|url=https://www.unicode.org/L2/L2021/21130-script-adhoc-rept.pdf|title=Recommendations to UTC #168 July 2021 on Script Proposals|website=The Unicode Consortium|author=Deborah Anderson, Ken Whistler, Roozbeh Pournader, Liang Ha|date=2021-07-26|access-date=2024-01-29}}</ref> As of January 2024, there is undergoing work for a proposal for {{tp|sitelen pona}}, cowritten by [[RebeccaUnder-ConScript BettencourtUnicode Registry]], maintainer of the [[Under-ConScriptRebecca Unicode RegistryBettencourt]], and many important figures in the Toki Pona [[community]].<ref>{{cite YouTube|id=W3I_x_rpwc8|title=nasin Juniko | toki lili pi mun #15|lang=tok|author={{tok|jan Kekan San}}|channel=Toki Pona VR|handle=TokiPonaVR|date=2024-01-24|access-date=2024-01-29}}</ref> A preliminary proposal was submitted on 16 April 2024.
 
{{tp|sitelen sitelen}} does not seem to be under consideration, as it has far fewer users<ref>{{cite web|url=https://tokiponacensus.github.io/results2022|title=Results of the 2022 Toki Pona census|wesbitewebsite=[[Toki Pona Censuscensus]]|published=GitHub|author={{tok|jan Tamalu}}|date=2022-10-03|access-date=2024-01-29}}</ref> and lacks font implementation of its nonlinear writing direction. Additionally, there is currently little existing architecture for scripts similar to {{tp|sitelen sitelen}}, such as {{w|Mayan hieroglyphs}}.
 
===Concerns===
Line 21:
*'''Recency'''. While the [[ISO 639-3]] code ought to relieve concerns that Toki Pona itself is transient, the words and features used to write it have been in flux. However, the UCSUR and the font {{tp|[[sitelen seli kiwen]]}} (both also by {{tok|jan Lepeka}}) may provide a working standard.
*'''Font standardization'''. Many fonts support different features and sets of characters, and implement them in different ways. While the UCSUR has largely resolved this to an extent, some common features remain unstandardized, such as directional {{sp|[[ni]]}}, {{sp|[[te to]]}}, and whether to use the halfwidth or ideographic {{w|Whitespace character|space}}. Also, there may be established UCSUR codepoints for features that should be handled in OpenType instead of Unicode, chiefly cartouche extension.
*'''{{tp|[[nimi sin]]}}'''. Which words ought to be encoded beyond those in the UCSUR is a point ripe for debate. A word's usage may not be proportional to usage of corresponding glyphs&mdash;as less used words have less recognized glyphs, and {{tp|nimi sin}} usage may differ between {{tp|sitelen pona}} and Toki Pona in general&mdash;so {{tok|[[Linku]]}} usage data may not be sufficient. The proposal team is planning to conduct research throughout 2024 to obtain better data for which words to encode.
**While the {{tok|[[Linku]]}} usage data seems useful for determining a cutoff point, many sub-widespread words have seen notable use and may be necessary to encode existing documents.
**The prospect of adding {{tp|nimi sin}} over time, as they meet some criteria for inclusion, is evocative of new emoji being added to account for the limitations of the original set. The Unicode Consortium may be motivated to avoid a similar situation by avoiding or postponing support for Toki Pona. If not, there could be a system outside of Unicode for encoding {{tp|nimi sin}}, possibly using a new UCSUR block.<ref>{{cite Discord|name={{tok|jan Pensa}}|username=jpensa|url=//discord.com/channels/301377942062366741/882652782509846548/944374678787588096|server={{tp|ma pona pi toki pona}}|channel=pali-musi|thread=nasin-Juniko|date=2023-11-02|message type=Pinned message}}<blockquote>
My idea for encoding rare {{tok|nimi sin}} that fonts still want to support, was to basically have two separate standards. Here's how I'd want that to look like in (hopefully) 1 or 2 years: