Probable issue in AO3

[Twilight666]

I was looking at this story:

https://archiveofourown.org/works/44635831

And in this story there are some parts that are in an alt!language and the author has set it up so that when hovering over them the text is replaced with the translation (there is a how-to on the story's notes at the end). From what I see you are taking it into account and the translations are added to the end, while there are links that looks like [x] in the text that are supposed to point to the translations (and links to redirect back to the OG text). However instead of moving to the appropriate locations in the epub, it instead redirects to the url in the story ie <sup>[ <a href="https://archiveofourown.org/works/44635831/chapters/#note1">1</a> ]</sup> instead of <sup>[ <a href="#note1">1</a> ]</sup> for example. I am not sure if this is a bug or if it is already covered in an existing setting that I don't know about

[JimmXinu]

AO3 allows authors to apply 'skins', AKA, custom CSS. Look in the source for that page for the <style type="text/css"> tag containing the #workskin rules. You will find there that the author has included all of the translations in the CSS.

FFF doesn't attempt to include author workskins because of the complexity involved and the fact FFF strives to make consistent output from all sources. The last time it came up I can quickly find is here.

You can copy this story's workskin CSS to FFF's output_css as long as you remove the #workskin selectors. Here's a truncated example. Note how much it also forces the appearance.

[https://archiveofourown.org/works/44635831]
add_to_output_css:
 a.hovertext1:after{content:'"Fermu ĝin, fermu ĝin!"'} a.hovertext1:hover:after, a.hovertext1:focus:after{content:'"Close it, close it!"';display:inline;background-color:#fff;color:#2a2a2a;border-bottom:1px solid #fff;position:relative;margin:0;padding:0} .hide{display:none} .....

FYI, in my testing this worked in EPUB, but when converted to AZW3 for Kindle, it broke again. Probably because Calibre Convert completely re-writes all CSS.

It's far more common, in my experience, for AO3 authors to use in-line CSS than workskins. Presumably because that's how WYSIWYG editor tend to work vs needing some relatively detailed knowledge of CSS to use workskins.

[Twilight666]

Just to clarify. The above solution (I haven't tried it yet because it looks a bit too complicated to use for a single story) would fix it so that it would look the same as the custom CSS (with the hover effects etc).

However my point was, that currently FFF downloads the story and adds the hover text at the end as notes. And FFF adds links both at the next to the text that the hover text should have been (that point to the notes) and links next to the notes that point back to the original text.

The problem is that those links are not created properly. Instead of pointing at locations in the epub, they are urls. A simple solution would be to delete the https://archiveofourown.org/works/44635831/chapters/ part that I mention in my original post.

To clarify. I am not asking if you can make the hover effects. I am asking if fixing the href links is possible, and if it would break anything else. When I opened the epub using an editor and did a find and replaced for the above, the end result worked fine.

[JimmXinu]

I assumed you'd (ideally) want the original behavior and didn't think too hard about the fall back behavior. So you're right to call me out on that.

In point of fact, FFF is not adding the superscripts or the translations as notes. Those were included in the HTML by the author and then concealed from view with the workskin CSS.

It's a bit impressive the lengths the author has gone to. To get the ease of hover-over translation and end note fall back requires the translations in two entirely different places.

The part that FFF is responsible for is changing the anchor links to absolute links. fix_relative_text_links is one of three options FFF has for helping make links in story text work 'correctly' that are on by default.

This fixes the internal anchor links for me:

[https://archiveofourown.org/works/44635831]
fix_relative_text_links:false

Arguably, anchor links like these shouldn't be made absolute even when fix_relative_text_links is on. I will look into that.