> I just launched my new Japanese-English dictionary app for Android this morning.

> The app is free to download and use, with a $2.99 IAP to disable ads.

> Please give it a try and let me know what you think!

> P.S. Thanks for your support over the months, it's been a real trip getting to this point. I made a New Years resolution to learn how to program for Android, and lo and behold here we are! I plan to continue improving gSho with the goal of making it one of the best Japanese-English dictionary apps on Android!

> Still early days for me trying it, but I can't see a romaji input
> option. If it's
> not there I think it needs one:
> (a) I don't want to have to turn on an alternative input method just
> to look up a word;
> (b) my Android tablet has a detachable keyboard, which I have to detach in order
> to use my IME (Simeji). It's a pain.
>
> If you are adding a romaji input option (and it's very easy to do this), allow
> for both Hepburn and Kunrei, i.e. both shi and si map to し, etc.

> I am strenuously avoiding going anywhere near app development. I think I'd get
> sucked in.

> I'd purposefully left out romaji input because I'm not a fan of romaji in general, but there's been a lot of demand for the feature so I may cave in and give the people what they want.

> There's also the issue of figuring out when to do a search for an English search term and when to convert romaji into kana and search by kana, but I'm sure I'll figure something out...

>> I am strenuously avoiding going anywhere near app development. I think I'd get
>> sucked in.
>
> I only meant it as a thank you for providing some insight into the inner workings
> of JMDict and the like! :P

> I don't like romaji either, and I refuse to use it for output, but input is
> another matter. It seems in Japan that the majority of keyboard
> users opt for romaji input rather than kana. But you rarely see
> Japanese written in romaji.

On Aug 16, 2013 6:35 AM, "iammatthewmiller" <masterkale@...> wrote:

> When you say that the majority of keyboard users in Japan opt for romaji, are you referring to how, for example, I'm able to type kana using wapuro-shiki romanization via an IME? I suppose the alternative would be using the confusing kana keyboard layout.

Yes, I saw the results of a survey a while back.  No idea why using a kana keyboard is less popular.

> Out of curiosity, what tablet and keyboard combination are you using?

It's an ASUS Transformer. The keyboard, which has an extra battery, USB, etc. detaches, so it can be either a screen-only tablet or a sort-of netbook. (My wife likes having a real keyboard.)

The alternative was a tablet plus a Bluetooth keyboard, but this seemed a better package.

Cheers

Jim

> - Kanji Lookup by component is almost finished and is one of the
> headline features of the upcoming 1.1.0 update. I've been struggling for
> the last two weeks with finding a font that has all 250-something
> components - I found two good, free fonts, but of course they're both
> missing one glyph and I don't have the experience to take the two and
> combine them. Do you know anyone versed in the arcane art of font magick
> who might be able to help? :P

> Now it's my turn to apologize for a late reply! :P

> - Out of curiosity, when you mentioned that there's a small bit of lag
> when searching, which direction were you searching? E->J? J->E?

> - Tag import/export is definitely on the list of features. I have to
> figure out a good way to do it because I have no guarantee that an export
> from one version will import in another *if* I ever do a massive update
> of the database to the latest version of JMDict/Tatoeba/etc...

> - Right now I'm handling dictionary updates.

> - Kanji Lookup by component is almost finished and is one of the
> headline features of the upcoming 1.1.0 update.

> - Advanced Searches are currently supported, specifically wildcards. You
> can use either * or ＊ anywhere in a search string as you'd expect.

> - What kinds of customization would you like to see in gSho? Beyond
> switching between EN and JP for the UI language, I hadn't given any serious
> thought towards other ways the user could customize the experience.

> I've been struggling for the last two weeks with finding a font
> that has all 250-something components

> Do you know anyone versed in the arcane art of font magick
> who might be able to help? :P

Nils:

- Thanks for noting the search lag, I reviewed the SQL search queries and discovered a couple of small things I could do to incrementally speed up searches in either direction. I may never figure out how to make them instantaneous, but there's a definite improvement.

- I'm glad you were able to figure out what I was saying about updates :P I'll add something in Settings that shows the version of JMDict that the app is currently using.

- The UI one phones is a bit cluttered, I'll admit. I'm thinking about hiding Vocabulary in the three-dot menu to give more room for a longer search bar.

---

Marcus:

> http://www.edrdg.org/jmdictdb/cgi-bin/entr.py?svc=jmdict&sid=&e=1122920

- Oh man, I had no idea the EDRDG site had such a page. I see that I have a LOT of work to do in improving the Entry Details view. You're not the first to suggest improvements to it, but you're definitely one of the few people who have provided me with a way to spot check my app's presentaton of JMDict entries versus the ideal presentation. I'll make it a priority to figure out how to make Entry Details look more like that link above.

- I could probably offer up a "quick report" button with some preset reports, provided there's an easy GET/POST-based way to submit such notices to the EDRDG site.

---

J:

I'm a fan of Gothic CJK fonts, so I'm more partial to IPAExGothic and WenQuanYi Zen Hei (not to mention the fact that Hanazono Mincho A is a hefty 20MB). Unfortunately, IPAExGothic is missing the ⺌ character, and WZH is missing 𠆢. I want to take ⺌ from WZH and put it into IPAExG, and then pare it down to just the 253 characters I need to display all the kanji components.

Based on what I've read of the two fonts' licenses, I should be fine modifying them like that provided I provide attribution in my app. Font Forge is incredibly obtuse (I tried going in and individually highlighting the characters I needed to preserve, but about twenty glyphs in I misclicked and lost my selections...) and FontLab Studio didn't seem to have an easy way to select all the glyphs. Is this something with which you'd be willing to assist me?

> I want to take ⺌ from WZH and put it into IPAExG,

> and then pare it down to just the 253 characters I need to display
> all the kanji components.

> Send me the exact set of Unicode characters you're using, and I'll

> strip out all the rest; since you're using 201A2 as 𠆢, obviously I
> can't just strip it down to the standard radical ranges. :-)

> Done. Full font here:

> http://s3.amazonaws.com/dotclue.org/ipa-comp.ttf

---In edict-jmdict@yahoogroups.com, <masterkale@...> wrote:

> Send me the exact set of Unicode characters you're using, and I'll

> strip out all the rest; since you're using 201A2 as 𠆢, obviously I
> can't just strip it down to the standard radical ranges. :-)

https://www.dropbox.com/s/yk1hte7xp8sep34/Kanji%20Components%20%2B%20Unicode%20Numbers.xlsx

Here's an Excel spreadsheet with all of the components and their Unicode numbers. Thanks for helping me out!

-Matt

I'm curious, did you use IPA font or IPAEx font as the basis for this? IPAEx (http://ipafont.ipa.go.jp/ipaexfont/download.html#en) is the more recent of the two and has a more permissive license. If you used the original IPA font, would it be too much to ask for the same compilation using IPAEx as the basis?

-Matt

> https://www.dropbox.com/s/yk1hte7xp8sep34/Kanji%20Components%20%2B%20Unicode%20Numbers.xlsx
>
> Here's an Excel spreadsheet with all of the components and their
> Unicode numbers. Thanks for helping me out!

> I'm curious, did you use IPA font or IPAEx font as the basis for this?

> - Thanks for noting the search lag, I reviewed the SQL search queries and
> discovered a couple of small things I could do to incrementally speed up
> searches in either direction. I may never figure out how to make them
> instantaneous, but there's a definite improvement.

> - I'm glad you were able to figure out what I was saying about updates :P
> I'll add something in Settings that shows the version of JMDict that the
> app is currently using.

> IPAex. For the final version, I'll have to change the name to
> meet the terms of the license (section 3.1), and include the
> FontLab file containing my modified version.

This is amazing, thank you so much! I finally had a chance to load it up in gSho and it works perfectly! I'm so excited right now, this was one of the last things holding up my release of the upcoming update.

Aside from attributions required by the licenses, how would you like to be attributed in gSho? I'll add you to the Acknowledgements section as thanks for your contribution!

-Matt

> Aside from attributions required by the licenses, how would you
> like to be attributed in gSho?

I've been pretty quiet about gSho lately, but I implemented some additional functionality today that I think will interest some of you here. That additional functionality is...romaji input!

When I first released gSho back in August, there was a huge demand for romaji input. I hemmed and hawed on whether I'd implement it or not out of an ideological dislike of Romaji but always kept it in the back of my mind as something I'd consider at a later time. Thanks to the release last Monday of the open-source Javascript IME WanaKana (http://wanakana.com/), I finally had an elegant way of offering Japanese kana input via any keyboard that can type the Roman alphabet!

By yesterday night I had WanaKana ported to Java and working in an Android app - I open-sourced the code as WanaKanaJava (https://github.com/MasterKale/WanaKanaJava/) under an MIT license.

I just finished incorporating WanaKanaJava into gSho for an upcoming release sometime this weekend. Here're some pictures of it in action:

Lowercase letters are converted to Hiragana

http://goo.gl/mWUebo

Uppercase letters are converted to Katakana

http://goo.gl/3sSfT9

Combined with the recent Kanji Lookup functionality introduced in 1.1.0 last week, gSho's becoming quite the nice little app if I do say so myself. It still has some rough edges that need polishing, but if you dismissed it earlier, maybe this will convince you to give it another try? :)

-Matt

> I've been pretty quiet about gSho lately, but I implemented some additional
> functionality today that I think will interest some of you here. That
> additional functionality is...romaji input!

> When I first released gSho back in August, there was a huge demand for
> romaji input. I hemmed and hawed on whether I'd implement it or not out of
> an ideological dislike of Romaji but always kept it in the back of my mind
> as something I'd consider at a later time.

> ....... Thanks to the release last Monday
> of the open-source Javascript IME WanaKana (http://wanakana.com/), I finally
> had an elegant way of offering Japanese kana input via any keyboard that can
> type the Roman alphabet!

> Lowercase letters are converted to Hiragana

> Uppercase letters are converted to Katakana

> Combined with the recent Kanji Lookup functionality introduced in 1.1.0 last
> week, gSho's becoming quite the nice little app if I do say so myself. It
> still has some rough edges that need polishing, but if you dismissed it
> earlier, maybe this will convince you to give it another try? :)

> I was hoping that you would provide support for both Hepburn and Kunrei

> romaji. Most IMEs do this and the romaji input option in WWWJDIC does too.

> It means that both "tu" and "tsu" map to つ, both "ti" and "chi" map to ち, etc.

> 

> Does WanaKana do this? If not, it should be upgraded. Should only be

> the addition

> of extra mappings.

I just did a spotcheck of the mappings and there appears to be support for multiple romanization schemes. "ti" and "chi" produce ち, while "tu" and "tsu" both map to つ. I'm no expert on the intricacies of either romanization system, though, so it might be easier to just peruse the list of mappings on GitHub to get a feel for how it'll handle transliteration: http://goo.gl/1e1Gjd (towards the bottom)

I eagerly await your feedback,

-Matt

> I just did a spotcheck of the mappings and there appears to be support for multiple romanization schemes. "ti" and "chi" produce ち, while "tu" and "tsu" both map to つ. I'm no expert on the intricacies of either romanization system, though, so it might be easier to just peruse the list of mappings on GitHub to get a feel for how it'll handle transliteration: http://goo.gl/1e1Gjd (towards the bottom)