From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5135 invoked from network); 3 Jul 2022 18:27:25 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2022 18:27:25 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Sun Jul 3 14:26:03 -0400 2022 Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id adaa4646 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Sun, 3 Jul 2022 11:25:49 -0700 (PDT) Message-ID: <9DCA81892DB8EB55794CE0EDEF529973@eigenstate.org> To: 9front@9front.org Date: Sun, 03 Jul 2022 14:25:48 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: overflow-preventing shader wrapper proxy Subject: Re: [9front] ktrans Reply-To: 9front@9front.org Precedence: bulk Quoth rgl@antares-labs.eu: > hi ori, > > > Is this japanese-only? Does it work for other languages? > > it supports input for english (passthrough/no processing), japanese > (hiragana, katakana and kanji), russian, greek and korean. > > > How hard is it to set up? The last tutorial I saw for it > > made it look like a pain, and I'm wondering if this patch > > makes it any better. If not, what work would we want to > > do on it? > > it needs to run before a rio session. you can either set it up on a > sub-rio running `@{ktrans; rio}` on a window, or put it on a line > right before starting rio in your $home/lib/profile. i'm thinking > these could be handy to have as examples in the man page, since it > isn't really obvious how you are supposed to get it running from the > current docs. Yes, adding an example of how to use it would be fantastic. > > I see some large hard-coded tables, as well as some dicts > > and scripts to generate dicts. Can we replace the dicts > > with scripts? > > i think so, yeah. the kanji.jisho is an adaptation of the libskk > dicts, the medium sized one to be more precise. i will try to figure > out the transformation Okamoto did and set up an automated fetch > script to pull them directly from the github.com/skk-dev/dict repo and > apply the filtering. users could then go to /lib/ktrans, and do > `grabdict [small|medium|large]` based on their preferences. it could > also be worth shipping with the small jisho, which is 54KB vs. the > 141KB medium one. I'd document where it comes from, but I'd just treat it like /lib/keyboard in kbdfs. Could add some script to pull them, but I'd be ok with just checking them in. I'm also ok with just keeping the tables, it just seemed odd to have a mix. Thanks!