New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aedict -> Ankidroid export bug in 3.40: visible HTML code #777

Closed
aedicted opened this Issue Jul 11, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@aedicted

aedicted commented Jul 11, 2017

The Kanji / readings field has been made editable during export to Ankidroid now.

However, the reading field contains weird HTML expressions in the AnkiDroid flashcard after export which weren't present before.

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Jul 11, 2017

Owner

Sorry about that - that was caused by #770 . If you leave the HTML there, in the reading field, it will mark the pitch in red in AnkiDroid. Yet, perhaps most of the users do not want that / do not care about pitch markings, so I guess I should introduce a setting for that. A checkbox setting whether to mark exported pitch in color or not; it should probably default to false.

Owner

mvysny commented Jul 11, 2017

Sorry about that - that was caused by #770 . If you leave the HTML there, in the reading field, it will mark the pitch in red in AnkiDroid. Yet, perhaps most of the users do not want that / do not care about pitch markings, so I guess I should introduce a setting for that. A checkbox setting whether to mark exported pitch in color or not; it should probably default to false.

@mvysny mvysny self-assigned this Jul 11, 2017

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Jul 11, 2017

Owner

Actually hard to say whether this is a bug or a feature :-D

Owner

mvysny commented Jul 11, 2017

Actually hard to say whether this is a bug or a feature :-D

@laxa88

This comment has been minimized.

Show comment
Hide comment
@laxa88

laxa88 Jul 12, 2017

(just chiming in) I think since users may have preference for how the "reading" field should be rendered (just raw text, or with-HTML), having a setting to toggle this would be helpful. :)

laxa88 commented Jul 12, 2017

(just chiming in) I think since users may have preference for how the "reading" field should be rendered (just raw text, or with-HTML), having a setting to toggle this would be helpful. :)

@aedicted

This comment has been minimized.

Show comment
Hide comment
@aedicted

aedicted Jul 12, 2017

aedicted commented Jul 12, 2017

@mvysny mvysny added bug and removed user feedback needed labels Jul 15, 2017

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Jul 15, 2017

Owner

@aedicted I completely agree. The format of 機能[きのう] is non-deterministic - it is not clear to which parts actually the reading applies: is it 能 or 機能 ? Internally, in Aedict, I'm using a different format: {機;き}{能;のう} which makes it clear.

The problem is that the abovementioned format of 機能[きのう] was designed by AnkiDroid and is used by AnkiDroid, so I need to stick to that for the foreseeable future.

Perhaps you should open a feature request for the guys at AnkiDroid to add support for the "curly brace" format? Incidentally, this format is also used by the FuriganaView component: https://github.com/sh0/furigana-view

Anyways this does not relate to the original bug report, please make a new bug report regarding this.

Owner

mvysny commented Jul 15, 2017

@aedicted I completely agree. The format of 機能[きのう] is non-deterministic - it is not clear to which parts actually the reading applies: is it 能 or 機能 ? Internally, in Aedict, I'm using a different format: {機;き}{能;のう} which makes it clear.

The problem is that the abovementioned format of 機能[きのう] was designed by AnkiDroid and is used by AnkiDroid, so I need to stick to that for the foreseeable future.

Perhaps you should open a feature request for the guys at AnkiDroid to add support for the "curly brace" format? Incidentally, this format is also used by the FuriganaView component: https://github.com/sh0/furigana-view

Anyways this does not relate to the original bug report, please make a new bug report regarding this.

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Jul 15, 2017

Owner

@laxa88 You're right - there's probably no other way than either not have the html at all, or let the user deal with it ;) Since after the field has been modified, it would be impossible to track the changes and add the html back in.

Owner

mvysny commented Jul 15, 2017

@laxa88 You're right - there's probably no other way than either not have the html at all, or let the user deal with it ;) Since after the field has been modified, it would be impossible to track the changes and add the html back in.

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Jul 17, 2017

Owner

Fixed in Aedict 3.41

Owner

mvysny commented Jul 17, 2017

Fixed in Aedict 3.41

@mvysny mvysny closed this Jul 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment