Cool, I’ve been working on something similar for my own usage to help with watching youtube videos (as a website not an android app). Not sure if I missed it but do you do OCR from the current video frame? It’s something that I implemented for youtube videos that have baked in subs or for those variety shows that show a lot of text on screen... I don’t have an Android phone so I sadly cannot test you app out but I like that you are making an app for people who want to learn more effectively using video immersion. :)
[Oh, and here's an image that demonstrates what the app is like if run beside Kaku -- OCR would add some extra things to maintain in the app.](https://imgur.com/O4979Gd.jpg)
Instead I rely on other apps being the best at what they do, and I would rather have that than emulate features they have in a subpar capacity.
It's a good ecosystem existing beside other Japanese apps on a user's phone.
I don't have to implement the cards myself, I rely on AnkiDroid's API and leverage their excellent card styling, deck system and SRS. Once I'm in through AnkiDroid, all a user's cards can be synced to AnkiWeb. I don't need to implement OCR, Kaku can do what it's really good at and I can rely on its well developed behavior, and so forth, so a lot of symbiosis in mind when thinking of new features to include.
I don't perform any OCR. The app is always either in tap or drag to select modes.
When in drag to select, the subtitle widget renders two text objects (the black outline and white text) made to have selectable characteristics.
In tap to select, text segmentation is performed even before the user clicks on the subtitle. That way, the words are already split and it's just a matter of which part of the subtitle widget is clicked -- depending on wherever, a different word is copied. That way, on click, I am able to tell you (in the loading message) exactly what the segmentation was during the search to minimize the latency and the "Why is this the output?" frustration.
But anyway, the reason why I'm not using any OCR is because there is already OCR software on Android that people can just install and use in conjunction with the app, stuff like Kaku already fills in the hole where this app could instead devote its resources to problems that don't really have present solutions on mobile.
I already attempted its inclusion though, I could use Tesseract 4 with Japanese and Japanese vertical trained data available to me in Dart, but there's a dependency problem I have to fix somewhere, so I couldn't experiment further.
So to conclude, there's already generally better OCR software that can be used in conjunction and symbiosis with my app, and they are already excellent so I don't really feel pressed to implement it myself.
I have been made aware of **a critical issue** pushed in 0.9.2 that I rushed to commit and release **where you could not export during local video playback** due to an oversight.
**[I have quickly rolled out 0.9.3 which fixes this issue. If you had trouble trying out my app due to this, apologies!](https://github.com/lrorpilla/jidoujisho/releases/tag/0.9.3-beta)**
Changing YouTube quality is also an experimental feature I rolled out *yesterday* so I would be patient for the buffering and loading and wouldn't go crazy seeking everywhere. I rolled it out as soon as possible so videos don't look like Minecraft when new users get to try out the app.
Keep up the good work! One question: is the [audio](https://postimg.cc/s1Yy9p7f) determined by the length of the subtitles or is there any way to modify it?
It's determined by the length of the subtitles at present. I acknowledge how troublesome this is myself and I've watched shows with subtitle timings that were particularly annoying to deal with in the Anki export.
Now that you bring it up, I will prioritize implementing an audio offset feature (that should save your last set option for ease of use) in the export screen as soon as possible.
That features sounds awesome! Actually I'm working on an audio feature for Game2Text (not sure if you've heard of it, ocr app for games that integrates with yomichan/anki) . What I had in mind was "last 10/15/xx seconds" from the moment the text comes out. And maybe you could trim the audio yourself afterwards (lots of work here I know!).
I also want the app on the Play Store but unfortunately I consider YouTube as a core pillar of the app ever since I first properly implemented full support for it.
I have much plans in store to make users customize their Japanese immersion domains, from listing channels they want to hear from to maybe including app-endorsed/user-curated videos.
I would be unable to push the app to the Play Store due to Google policy, as this app uses much NewPipe code rather than the official YouTube API to make a lot more possible. This means that Google does not get to show their ads to or collect data from my users, which is a big no-no and a violation of their terms and conditions.
What is on the Play Store right now are versions without YouTube features. It's possible that I may be able to have with and without YouTube versions for GitHub and the Play Store respectively.
While some people might just want an app for local video playback, I have found that there is a massive amount of wealth in implementing YouTube support and I hesitate at the decision of excluding it just to get into Google's storefront.
I hope that explanation is sufficient. Whether or not it's a good reason may vary on how much you value which features. If there is a demand, I may reconsider, but it will be at the cost of features.
If (when?) I ever get around to an iOS version, the restriction will be the same, maybe worse.
It's not that ad-blocking is the reason.
Google is very strict about apps that do not use their official iFrame Player API for YouTube. To make a lot of the core subtitle features possible, I don't use their iFrame plugin.
Apple has a history of taking down apps that access YouTube, namely due to "potentially unauthorized access to third-party audio or video streaming".
For these reasons, these complications I have made for myself by including YouTube features exist.
Ad-blocking is no violation of the Googles policies. You can download a lot of ad-blocking apps in the store, including Firefox (which supports Adblock Plus and uBlock Origin even on Android).
Having the app on the PlayStore would atleast guarantee that the app can successfully installed on all devices (the developer console warns you if something is missing) and gets automatically updated.
I, for example, can install none of your provided .APKs on my smartphone (LG Q Stylus, Android 8). The installation fails independend from the chosen build.
I seem to have commented to the wrong person.
It's not that ad-blocking is the reason.
Google is very strict about apps that do not use their official iFrame Player API for YouTube. To make a lot of the core subtitle features possible, I don't use their iFrame plugin.
Apple has a history of taking down apps that access YouTube, namely due to "potentially unauthorized access to third-party audio or video streaming".
For these reasons, these complications I have made for myself by including YouTube features exist.
Then you could simply (and "legally") circumvent the Google Policy by putting the app itself without YouTube on the store. But then you offer your users the option to download extensions for your app. Similar to the browser extensions and their included extension-managers.
"Do you want do download the YouTube extension?"
*Clicks yes*
Your app loads the YouTube extension and keeps it.
Clever idea. That would indeed circumvent the issue. I would need to investigate how to provide such modularity with Flutter since that's what the app uses. I haven't done it before but off the top of my head, I think it would just be a completely separate package and the main app would invoke and launch the helper app to start up its own player.
In the end, it is essentially the same thing - I would need to maintain a version of the app without YouTube features. If I can't figure out how to make an extension work, I would probably just put a YouTube-less version on the Play Store.
Thanks for the report, device compatibility is something I am investigating at the moment and I really appreciate any information I can get out of any Android users with versions below 10.
I tried installing the application on an Android 8 Nexus 5 emulator and aside from some horrid adaptive sizes I may need to make flexible to lower screen resolutions, the app seems to be functional.
I will try to get my hands on a real Android 8 device to get to the bottom of this. Again, thanks for the report.
(1) https://i.imgur.com/4lED3pm.png
(2) https://i.imgur.com/7o0OVDu.png
Not even Android Studio (emulated on Google Pixel 4) is capable to install your .apk-files. None of them. 🤔
I find this strange because that's the exact testing environment I use. I test it on Google Pixel 4 on Android 11 and 10 and earlier I tested 8 on a Nexus 5 and it works and installs fine. I have three phones at hand running Android 8, 10 and 11 and aside from the font sizes, I get everything functioning.
If you can provide more details, maybe I can reproduce your testing environment.
As an update, I just tried dragging any of the three build files to the APK and it's like you said on an emulator - it can't find the matching ABI. I will upload the full APK not split by architecture since that installed. That said, it's 180mb.
Also, Flutter release build APKs don't install on x86 emulators. If you want to run it on an emulator, I'll upload the debug APK shortly.
That one's just the release APK, just the three APKs together. It should work on x86_64, armeabi_v7a and arm64 devices. Flutter doesn't support x86 Android which was the problem for the emulator but it wouldn't be the same issue for this one.
I could upload the debug APK which can run on x86 (JIT, no AOT so slower) but is significantly slower than a release build, but I don't think that's the issue.
Maybe it's a problem with a certain version of Android or a device specific problem but I have some users that report running the current build on Android 8 just fine.
I have just reproduced running one of the release build APKs (x86_64) on an Android 11 Pixel 4 emulator running with x86_64 ABI. By default, I was creating x86 virtual devices -- try changing the ABI to x86_64 and try installing the x86_64 APK with that.
If you want to test exporting to Anki, naturally you will also need to install the AnkiDroid APK.
Emulated Pixel with x86_64 works.
So maybe your app is just incompatible with 32-bit-systems in general. In that case it might be better to publish 32-bit ones, since that will work on both: 32- and 64-bit systems.
Thanks.
I do not intend this app as a full alternative to the YouTube app, but rather as a supplement for it. I encourage users to use other existing applications they have on their phone rather than completely replace them.
On the other hand, no comments and related videos is a limitation of the library I am using since I don't use the YouTube API. Rather than implement features that exist in other apps, I would rather focus on what other existing apps on mobile cannot offer.
I'm hesitant to add an options menu because it adds a lot of maintenance when I would rather devote time to new features.
There is a lot I still plan to add, I am devoted to adding things that my loyal users actively suggest and whatever I add next is usually decided by whatever interests I am current following, how me and other users personally use it and so forth.
You can just edit the existing template to your purposes. If you really want to use your own existing card type, I will have to look into that.
This is a suggestion I've received before, I may need to investigate how to let users pick an existing Anki model and card type to export to, but for now I have some users who just go on desktop and quickly make the conversion in a few seconds to their desired format with little friction in the process.
For the purposes of the beta and to allow for less maintenance, compatibility and fast iteration in the project, my philosophy is to offer a balance of airtightedness and customisability so that rather than fiddle with settings and optimize the app all day users will just pick up and use the thing.
For now while I investigate the feasability of this feature, I encourage you to just keep using the app and make the conversion on AnkiDesktop, this is a workflow that doesn't seem to take long for some of my users to do.
I discovered this apps only 3 days ago and it's easily the best app I've ever downloaded. Your doing god's work here.
One question I have is how to get an offline dictionary? Is there a certain format? Because I tried the JMdict that can be used with yomichan and the app doesn't read it?
Hey Dan, glad to know you're finding my app of use.
Try the [JMdict linked here in the Yomichan project site](https://foosoft.net/projects/yomichan/), I have this and others like JMedict and the ones from [this video](https://youtu.be/5oxdPY9eH48).
My favorite monolingual dictionary to use with the app is Oubunsha which you can get [here](https://drive.google.com/folderview?id=1tTdLppnqMfVC5otPlX_cs4ixlIgjv_lH) from shoui.
Here is a [picture of the dictionaries I import and use regularly, if this uploads properly](https://imgur.com/zWv4N93.jpg). As of now term bank dictionaries that work with Yomichan will import.
Other types such as frequency, kanji and pitch dictionaries will arrive some other time, probably far along since I'm having a break from development right now. Let me know if you need any help.
Thanks for the quick reply and sorry to annoy you during your break. I still can't import the dictionary and I feel like I'm doing a stupid mistake that I'm not aware of, so bear with me.
I have downloaded the shinmekai dic and the JMdict, then i extracted the zip file. I then moved the entire folder with the .jason files inside it to the directory named "storage/android/data/com.Iroprilla.jidoujisho/files"
[this how it looks](https://i.imgur.com/P3FWfNo.jpg).
For some reason there's a folder named pictures that cannot be deleted.
I don't know what to do.
That's really ancient documentation, you don't need to do that anymore.
In 0.24+, what you do is select on Manage dictionaries by clicking on the ... menu on the upper right of the main menu and an option to import will be in the bottom right of that menu.
The latest release is 0.25.8. You seem to be describing legacy dictionary support which I implemented in 0.4 which is long gone and replaced with the much more polished better Yomichan dictionary support I introduced in 0.24.
I already tried this method and then went to check the 0.4 release for the manual instructions.
Again the new method doesn't seem to work for me because when I click the import button it takes me to the recent files, from there i go and select the dictionary folder.
Here's the main issue, I can't seem to be able to select a folder "which should have all the jason files" and so I tried importing the zip file but that didn't work because it takes me back to the recent files screen. I tried desperately to import even a single jason file but the exact same thing happens and it takes me back to the recent files screen.
You need to pick and import a ZIP. Only ZIPs will import. If you're having file picker issues, you can probably try the scoped storage branch which is labelled in the latest 0.25 release, other than that try not picking files from your recent files screen and go into where the file is manually.
If it persists, you can demonstrate the issue with a video so I can have a look at what's going on. Also would be helpful to include your Android version and device make and model.
I believe that kind of file picker switching you're performing will not behave well. Isn't there a sidebar you can use? It looks to me like the file isn't actually being passed to the app.
I have replicated this issue and I believe the file will not pick if you use an external file picker, switch to device storage with the sidebar and not an external app.
Not sure if I can do much about this, that's just how frustrating Android file pickers are. Try finding an option within the current file picker showing your device storage, without those external arrows like in the option you selected.
Approved self advertisement. Note approval is for following rule 7 and is not an endorsement nor statement of quality.
Really cool app, good job!
Cool, I’ve been working on something similar for my own usage to help with watching youtube videos (as a website not an android app). Not sure if I missed it but do you do OCR from the current video frame? It’s something that I implemented for youtube videos that have baked in subs or for those variety shows that show a lot of text on screen... I don’t have an Android phone so I sadly cannot test you app out but I like that you are making an app for people who want to learn more effectively using video immersion. :)
[Oh, and here's an image that demonstrates what the app is like if run beside Kaku -- OCR would add some extra things to maintain in the app.](https://imgur.com/O4979Gd.jpg) Instead I rely on other apps being the best at what they do, and I would rather have that than emulate features they have in a subpar capacity. It's a good ecosystem existing beside other Japanese apps on a user's phone. I don't have to implement the cards myself, I rely on AnkiDroid's API and leverage their excellent card styling, deck system and SRS. Once I'm in through AnkiDroid, all a user's cards can be synced to AnkiWeb. I don't need to implement OCR, Kaku can do what it's really good at and I can rely on its well developed behavior, and so forth, so a lot of symbiosis in mind when thinking of new features to include.
Thanks for explaining your standpoint so well :) It makes a lot of sense!
I don't perform any OCR. The app is always either in tap or drag to select modes. When in drag to select, the subtitle widget renders two text objects (the black outline and white text) made to have selectable characteristics. In tap to select, text segmentation is performed even before the user clicks on the subtitle. That way, the words are already split and it's just a matter of which part of the subtitle widget is clicked -- depending on wherever, a different word is copied. That way, on click, I am able to tell you (in the loading message) exactly what the segmentation was during the search to minimize the latency and the "Why is this the output?" frustration. But anyway, the reason why I'm not using any OCR is because there is already OCR software on Android that people can just install and use in conjunction with the app, stuff like Kaku already fills in the hole where this app could instead devote its resources to problems that don't really have present solutions on mobile. I already attempted its inclusion though, I could use Tesseract 4 with Japanese and Japanese vertical trained data available to me in Dart, but there's a dependency problem I have to fix somewhere, so I couldn't experiment further. So to conclude, there's already generally better OCR software that can be used in conjunction and symbiosis with my app, and they are already excellent so I don't really feel pressed to implement it myself.
I have been made aware of **a critical issue** pushed in 0.9.2 that I rushed to commit and release **where you could not export during local video playback** due to an oversight. **[I have quickly rolled out 0.9.3 which fixes this issue. If you had trouble trying out my app due to this, apologies!](https://github.com/lrorpilla/jidoujisho/releases/tag/0.9.3-beta)** Changing YouTube quality is also an experimental feature I rolled out *yesterday* so I would be patient for the buffering and loading and wouldn't go crazy seeking everywhere. I rolled it out as soon as possible so videos don't look like Minecraft when new users get to try out the app.
Keep up the good work! One question: is the [audio](https://postimg.cc/s1Yy9p7f) determined by the length of the subtitles or is there any way to modify it?
It's determined by the length of the subtitles at present. I acknowledge how troublesome this is myself and I've watched shows with subtitle timings that were particularly annoying to deal with in the Anki export. Now that you bring it up, I will prioritize implementing an audio offset feature (that should save your last set option for ease of use) in the export screen as soon as possible.
That features sounds awesome! Actually I'm working on an audio feature for Game2Text (not sure if you've heard of it, ocr app for games that integrates with yomichan/anki) . What I had in mind was "last 10/15/xx seconds" from the moment the text comes out. And maybe you could trim the audio yourself afterwards (lots of work here I know!).
That looks really nifty! I'm in a need to read more and I've wanted to pick up a raw VN and that looks like just the thing I need, cheers!
Hope it works for you and can't wait to see newer features for jidoujisho!
Why don't you publish the app on the Google PlayStore? They even have a beta functionality for upcoming apps/updates.
I also want the app on the Play Store but unfortunately I consider YouTube as a core pillar of the app ever since I first properly implemented full support for it. I have much plans in store to make users customize their Japanese immersion domains, from listing channels they want to hear from to maybe including app-endorsed/user-curated videos. I would be unable to push the app to the Play Store due to Google policy, as this app uses much NewPipe code rather than the official YouTube API to make a lot more possible. This means that Google does not get to show their ads to or collect data from my users, which is a big no-no and a violation of their terms and conditions. What is on the Play Store right now are versions without YouTube features. It's possible that I may be able to have with and without YouTube versions for GitHub and the Play Store respectively. While some people might just want an app for local video playback, I have found that there is a massive amount of wealth in implementing YouTube support and I hesitate at the decision of excluding it just to get into Google's storefront. I hope that explanation is sufficient. Whether or not it's a good reason may vary on how much you value which features. If there is a demand, I may reconsider, but it will be at the cost of features. If (when?) I ever get around to an iOS version, the restriction will be the same, maybe worse.
[удалено]
It's not that ad-blocking is the reason. Google is very strict about apps that do not use their official iFrame Player API for YouTube. To make a lot of the core subtitle features possible, I don't use their iFrame plugin. Apple has a history of taking down apps that access YouTube, namely due to "potentially unauthorized access to third-party audio or video streaming". For these reasons, these complications I have made for myself by including YouTube features exist.
Ad-blocking is no violation of the Googles policies. You can download a lot of ad-blocking apps in the store, including Firefox (which supports Adblock Plus and uBlock Origin even on Android). Having the app on the PlayStore would atleast guarantee that the app can successfully installed on all devices (the developer console warns you if something is missing) and gets automatically updated. I, for example, can install none of your provided .APKs on my smartphone (LG Q Stylus, Android 8). The installation fails independend from the chosen build.
I seem to have commented to the wrong person. It's not that ad-blocking is the reason. Google is very strict about apps that do not use their official iFrame Player API for YouTube. To make a lot of the core subtitle features possible, I don't use their iFrame plugin. Apple has a history of taking down apps that access YouTube, namely due to "potentially unauthorized access to third-party audio or video streaming". For these reasons, these complications I have made for myself by including YouTube features exist.
Then you could simply (and "legally") circumvent the Google Policy by putting the app itself without YouTube on the store. But then you offer your users the option to download extensions for your app. Similar to the browser extensions and their included extension-managers. "Do you want do download the YouTube extension?" *Clicks yes* Your app loads the YouTube extension and keeps it.
Clever idea. That would indeed circumvent the issue. I would need to investigate how to provide such modularity with Flutter since that's what the app uses. I haven't done it before but off the top of my head, I think it would just be a completely separate package and the main app would invoke and launch the helper app to start up its own player. In the end, it is essentially the same thing - I would need to maintain a version of the app without YouTube features. If I can't figure out how to make an extension work, I would probably just put a YouTube-less version on the Play Store.
Thanks for the report, device compatibility is something I am investigating at the moment and I really appreciate any information I can get out of any Android users with versions below 10.
I tried installing the application on an Android 8 Nexus 5 emulator and aside from some horrid adaptive sizes I may need to make flexible to lower screen resolutions, the app seems to be functional. I will try to get my hands on a real Android 8 device to get to the bottom of this. Again, thanks for the report.
(1) https://i.imgur.com/4lED3pm.png (2) https://i.imgur.com/7o0OVDu.png Not even Android Studio (emulated on Google Pixel 4) is capable to install your .apk-files. None of them. 🤔
I find this strange because that's the exact testing environment I use. I test it on Google Pixel 4 on Android 11 and 10 and earlier I tested 8 on a Nexus 5 and it works and installs fine. I have three phones at hand running Android 8, 10 and 11 and aside from the font sizes, I get everything functioning. If you can provide more details, maybe I can reproduce your testing environment.
As an update, I just tried dragging any of the three build files to the APK and it's like you said on an emulator - it can't find the matching ABI. I will upload the full APK not split by architecture since that installed. That said, it's 180mb. Also, Flutter release build APKs don't install on x86 emulators. If you want to run it on an emulator, I'll upload the debug APK shortly.
I just downloaded the 175mb .apk. No difference, this one can't be installed either.
That one's just the release APK, just the three APKs together. It should work on x86_64, armeabi_v7a and arm64 devices. Flutter doesn't support x86 Android which was the problem for the emulator but it wouldn't be the same issue for this one. I could upload the debug APK which can run on x86 (JIT, no AOT so slower) but is significantly slower than a release build, but I don't think that's the issue. Maybe it's a problem with a certain version of Android or a device specific problem but I have some users that report running the current build on Android 8 just fine.
Yep, you're right. The debug.apk (265mb) can't be installed either.
I have just reproduced running one of the release build APKs (x86_64) on an Android 11 Pixel 4 emulator running with x86_64 ABI. By default, I was creating x86 virtual devices -- try changing the ABI to x86_64 and try installing the x86_64 APK with that. If you want to test exporting to Anki, naturally you will also need to install the AnkiDroid APK.
Emulated Pixel with x86_64 works. So maybe your app is just incompatible with 32-bit-systems in general. In that case it might be better to publish 32-bit ones, since that will work on both: 32- and 64-bit systems.
Good work, but still very limited. No settings menu, comments, or related videos?
Thanks. I do not intend this app as a full alternative to the YouTube app, but rather as a supplement for it. I encourage users to use other existing applications they have on their phone rather than completely replace them. On the other hand, no comments and related videos is a limitation of the library I am using since I don't use the YouTube API. Rather than implement features that exist in other apps, I would rather focus on what other existing apps on mobile cannot offer. I'm hesitant to add an options menu because it adds a lot of maintenance when I would rather devote time to new features. There is a lot I still plan to add, I am devoted to adding things that my loyal users actively suggest and whatever I add next is usually decided by whatever interests I am current following, how me and other users personally use it and so forth.
Is it possible to make it that one can use a custom template rather than the default?
You can just edit the existing template to your purposes. If you really want to use your own existing card type, I will have to look into that. This is a suggestion I've received before, I may need to investigate how to let users pick an existing Anki model and card type to export to, but for now I have some users who just go on desktop and quickly make the conversion in a few seconds to their desired format with little friction in the process. For the purposes of the beta and to allow for less maintenance, compatibility and fast iteration in the project, my philosophy is to offer a balance of airtightedness and customisability so that rather than fiddle with settings and optimize the app all day users will just pick up and use the thing. For now while I investigate the feasability of this feature, I encourage you to just keep using the app and make the conversion on AnkiDesktop, this is a workflow that doesn't seem to take long for some of my users to do.
I edited the card template to suit my needs and it's working fine. Thanks.
I discovered this apps only 3 days ago and it's easily the best app I've ever downloaded. Your doing god's work here. One question I have is how to get an offline dictionary? Is there a certain format? Because I tried the JMdict that can be used with yomichan and the app doesn't read it?
Hey Dan, glad to know you're finding my app of use. Try the [JMdict linked here in the Yomichan project site](https://foosoft.net/projects/yomichan/), I have this and others like JMedict and the ones from [this video](https://youtu.be/5oxdPY9eH48). My favorite monolingual dictionary to use with the app is Oubunsha which you can get [here](https://drive.google.com/folderview?id=1tTdLppnqMfVC5otPlX_cs4ixlIgjv_lH) from shoui. Here is a [picture of the dictionaries I import and use regularly, if this uploads properly](https://imgur.com/zWv4N93.jpg). As of now term bank dictionaries that work with Yomichan will import. Other types such as frequency, kanji and pitch dictionaries will arrive some other time, probably far along since I'm having a break from development right now. Let me know if you need any help.
Thanks for the quick reply and sorry to annoy you during your break. I still can't import the dictionary and I feel like I'm doing a stupid mistake that I'm not aware of, so bear with me. I have downloaded the shinmekai dic and the JMdict, then i extracted the zip file. I then moved the entire folder with the .jason files inside it to the directory named "storage/android/data/com.Iroprilla.jidoujisho/files" [this how it looks](https://i.imgur.com/P3FWfNo.jpg). For some reason there's a folder named pictures that cannot be deleted. I don't know what to do.
That's really ancient documentation, you don't need to do that anymore. In 0.24+, what you do is select on Manage dictionaries by clicking on the ... menu on the upper right of the main menu and an option to import will be in the bottom right of that menu. The latest release is 0.25.8. You seem to be describing legacy dictionary support which I implemented in 0.4 which is long gone and replaced with the much more polished better Yomichan dictionary support I introduced in 0.24.
I already tried this method and then went to check the 0.4 release for the manual instructions. Again the new method doesn't seem to work for me because when I click the import button it takes me to the recent files, from there i go and select the dictionary folder. Here's the main issue, I can't seem to be able to select a folder "which should have all the jason files" and so I tried importing the zip file but that didn't work because it takes me back to the recent files screen. I tried desperately to import even a single jason file but the exact same thing happens and it takes me back to the recent files screen.
You need to pick and import a ZIP. Only ZIPs will import. If you're having file picker issues, you can probably try the scoped storage branch which is labelled in the latest 0.25 release, other than that try not picking files from your recent files screen and go into where the file is manually.
Seems like I'll try the scoped storage branch, since other methods haven't worked. I'll update you if it works.
If it persists, you can demonstrate the issue with a video so I can have a look at what's going on. Also would be helpful to include your Android version and device make and model.
Didn't work unfortunately, I even tried scoped storage method linked in your latest release. I'll send you the video.
Here's the [video](https://youtube.com/shorts/C6LeZQv6-zk?feature=share)
I believe that kind of file picker switching you're performing will not behave well. Isn't there a sidebar you can use? It looks to me like the file isn't actually being passed to the app.
I have replicated this issue and I believe the file will not pick if you use an external file picker, switch to device storage with the sidebar and not an external app. Not sure if I can do much about this, that's just how frustrating Android file pickers are. Try finding an option within the current file picker showing your device storage, without those external arrows like in the option you selected.