"Kanji of the request" textbox converting Kanji to Hiragana

[ospalh]

"Kanji of the request" textbox converting Kanji to Hiragana

[ospalh]

Just to make sure, the content of your “Reading” field is both kanji and kana, as in 「土星[どせい]」, the way it comes out of the Japanese support add-on’s reading generation?

The add-on isn't really up to the task to do a request using two fields as the text source, taking kanji from one and kana from the other. Maybe that is something that can be added. (Maybe with some kind of True/False switch in the code, that the user has to change, see below.)

If you have the kanji in the “Reading” field, the problem is much trickier.
In that case, could you perhaps send a sample deck (per e-mail). Just exporting a few cards and sending that would be fine.

It's not hard to go and change get_fields to "audio_field_keys = ['reading', 'sound']"

That's the nice thing about a scripting/interpreted language like Python.

(Until i get some reports that people didn’t manage to do this kind of change in the code, i feel this is good enough. I don‘t really want to spend too much time writing an elaborate GUI for something that can be done quickly in a text editor.)

[flameiguana]

I would also like it if the kanji side of the reading filed was taken from 'expression', and the 'reading' field(which should be in kana) was used as the kana side.
Ignoring the kanji causes japanese pod to not return anything, because sometimes the same kana can use different kanji.
Here is how my cards are set up.
Expression: 漢字
Reading: かんじ
Audio:

[ospalh]

I kind of see the point.

At the moment the way the text is selected is rather field based, getting the data out of two fields instead of looking at just one field may be a bit of work. (Too much for me to bother with, if you are out of luck.)

Then again, having kanji and kana in one field as in 「漢字[かんじ]」 has a number of advantages:

• This add-on works better (d'uh)
• You can let the Japanese Support add-on generate the reading for you
• The {{furigana:NN}} template works, along with {{kanji:NN}}, {{kana:NN}}

If you want to keep the pure kana field, you could rename it (to, say, “Just kana”) and re-add a new, empty field “Reading”.

Then you could have the Japanese Support add-on re-generate the readings and only fix those were there is a problem/ambiguity (e.g. 「今日[きょう]」 versus 「今日[こんにち]」), either go through your collection or fix them in the download dialog. That’s more or less what it is there for. (Although when you spot a true error there, you should fix it in the note as well.) In the future you can then just type/copy-paste the kanji and get the reading done for you.

[flameiguana]

Thanks for the suggestion. I wasn't using the Japanese Support plugin, so I had no idea why that was your preferred way of fetching the reading. Here's what my fields look like now, after converting note types.

Was the bracket notation mentioned thing in your guide for the plugin? If so, I must have missed it.

In case you were wondering, I kept my old reading field because I prefer not to use the furigana display thing, as the placement of the kana is sometimes ambiguous.

[ospalh]

Was the bracket notation mentioned thing in your guide for the plugin?

Not really. See #11

[ospalh]

I guess i should have written this a bit earlier.
I have added code that should deal with this issue to get_fields.py. The point is that

• at the moment i don't really have time to test this too much
• and the manual is not ready.

So i havent pushed this to AnkiWeb.

But i guess getting the add-on from here, and when you have installed it to the addons folder changing the naked_reading to True should work.

[ospalh]

I have now

• renamed the variable
• and rolled this out.