07:32:01 <ErCiccione[m]> Why do we enforce a baseurl which is the same as the url?
07:32:27 <ErCiccione[m]> I remember rehrar adding it long ago saying that it was needed to build properly? Why was that the case?
07:33:01 <ErCiccione[m]> Our baseurl is set wrong and causes a bunch of issues
07:33:23 <ErCiccione[m]> binaryfate: what's the command you use to buil the website?
07:35:32 <ErCiccione[m]> Oh, i think i understood. Looks like the multilingual plugin needs it set in a weird way, which is not it's original purpose.
07:35:35 * ErCiccione[m] goes dig
08:10:56 <xmrmatterbridge> <rehrar> Erciccione remember that this whole thing is held together by duct tape and string.
08:12:04 <ErCiccione[m]> but why?
08:12:34 <xmrmatterbridge> <rehrar> Because the multilingual thing was horrific to work with as I recall.
08:12:51 <xmrmatterbridge> <rehrar> Everything broke if it was not just so.
08:13:11 <xmrmatterbridge> <rehrar> I reached out to the creators of jelyll and the plug-in at the time and didn't receive a response.
08:13:37 <xmrmatterbridge> <rehrar> And I'm a designer, not a Ruby/liquid specialist, so I found my workarounds.
08:14:33 <ErCiccione[m]> Yeah i understand
08:14:49 <xmrmatterbridge> <rehrar> If you can solve this thing then I will sing your praises.
08:15:42 <ErCiccione[m]> Many structures need to be completely rethought. I could work on it, but that would be extremely time consuming, i would basically work on only that
08:16:49 <ErCiccione[m]> which is not really ideal IMO. I'm already slowing fixing things here and there, but the groundbreaking (ah! i learned!) changes would require much more time
08:17:30 <ErCiccione[m]> and btw the multilingual plugin we use it's not maintained anymore
08:17:47 <ErCiccione[m]> they are looking for volunteers willing to maintain it
08:18:48 <ErCiccione[m]> Anyway, i fixed most of the very important things that the introduction of the plugin broke: like meta tags, sitemap and various structure. The main problem remain the way we handle user guides and the moneropedia
09:13:52 <ErCiccione[m]> Yeah we have to stop using baseurl the way we do.
09:14:53 <ErCiccione[m]> or it will break things foreva
09:16:14 <ErCiccione[m]> binaryfate please let me know the jekyll command you use to build. Would be also good to have the nginx file uploaded on the repository, so we can see how/if nginx influences the process
09:22:22 <ErCiccione[m]> To sum up the situation: the i18n plugin needs a baseurl or it won't build. We enforce a baseurl and we give it to the plugin, but that structure is wrong, because it's an entire url and shouldn't be like that. Jekyll's urls work like this: https://byparker.com/img/what-is-a-baseurl.jpg. Problem is that jekyll and all related plugins obviously use the correct formatting
09:22:58 <ErCiccione[m]> which means we will always have incompatibilities with plugins and other jekyll's narive structures
09:24:25 <ErCiccione[m]> that's also the reason why the sitemap generator was broken. The plugin we use to generate it was using the correct structure, but when the wrong basuerl was enforced it broke that plugin too. Luckily the plugin was manually added so i could just edit the ruby script
09:25:26 <ErCiccione[m]> but this is a problem that will come back to bite our ass. So yeah,bottom line is we need to change the way we use the baseurl and possibly the way we build the website
09:26:41 <ErCiccione[m]> I think we could solve by using an empty baseurl in the _config.yml file, but i cannot be sure until i know how we deploy getmonero on the server
16:20:14 <rehrar> ErCiccione[m]: is there another plugin that we can swap to that is maintained?
16:20:23 <rehrar> as I'm guessing it's not currently in our capacity to maintain this thing
16:22:16 <ErCiccione[m]> I took a look some months ago and IIRC there is at least another one that is actively maintained, but i wouldn't switch at the moment.
16:22:26 <rehrar> link for me to look?
16:22:31 <rehrar> if you have the time
16:22:35 <rehrar> at your convenience
16:29:33 <ErCiccione[m]> I have to look for it, i honestly don't remember even the name of the plugin
16:32:59 <ErCiccione[m]> the present plugin works very good for us though, i wouldn't change it unless we really have to for some reason. Beside changing the structure of the entire website, we would have to deal with weblate as well. Would be a major change
17:31:52 <sarang> What's supposed to be different with this PR? https://github.com/monero-project/monero-site/pull/1145/files
17:31:59 <sarang> e.g. on the Hangouts page, the top social icons appear identical
17:32:10 <sarang> Also, have reviewed some other PRs
17:37:01 <ErCiccione[m]> sarang: Yes, i see thanks. That PR add an icon to all external links, but not to social icons, since they already show quite clearly that you are going somehwere else (twitter, github, etc)
17:37:13 <ErCiccione[m]> if you browse the website, you'll see all external links have the icon now
17:37:54 <ErCiccione[m]> see the MRL page for example
17:39:01 <sarang> Agreed with the other commenter who noted that `id` should be `class`
17:39:20 <ErCiccione[m]> yep. Didn't think about that, will change it
17:40:16 <sarang> Are external links distinguished for other types of browsers, like screen readers?
17:40:39 <sarang> I noticed e.g. that there's no hover text or anything to clearly indicate external other than the little superscript icon
17:42:19 <ErCiccione[m]> I don't think they are, but i think that's the standard. I used wikipedia for "inspiration" and they don't have any tooltip either. I guess it's because the screen reader reads the link itself.
17:42:49 <sarang> IMO it would be nice UX to have hover text indicating "external link" or something
17:43:03 <sarang> And perhaps this would also help something like a screen reader or other browser types
17:43:19 <sarang> If the standard is "not great for accessibility" then let's lead past the standard
17:44:33 <sarang> Oh wait, maybe just a proper `alt` on the image would do it
17:44:43 <sarang> Right now it's an image with no `alt`, which AIUI is bad for accessibility
17:45:39 <ErCiccione[m]> No, my point is that a tooltip doesn't help accessibility. The screen readers reads the link AFAIK, there is no point in having additional text saying it's an external link. It's obvious when it's read.
17:45:56 <ErCiccione[m]> Anyway, i will look it up to see what's the best course of action in this case
17:46:49 <ErCiccione[m]> Also, that icon is not an image
17:46:50 <sarang> Should the image not still have an `alt`?
17:46:54 <sarang> it's an SVG, no?
17:46:57 <sarang> Or am I misreading
17:47:37 <ErCiccione[m]> oh sorry, i confuded myself with the other icon, which has a tooltip (the info button)
17:47:58 <ErCiccione[m]> the external link icon is an svg, yes
17:48:07 <sarang> I don't mean to sound pedantic on this, but I think it's important to address accessibility from the start, whenever possible
17:48:19 <sarang> it's the right thing to do
17:48:39 <sarang> If it isn't an accessibility problem, great
17:49:51 <ErCiccione[m]> I think that's important too, don't misunderstand me. I just don't see how adding a tooltip will help accessibility in this case. Beside the fact that the icon is added through css selectors, which makes things much more complicated.
17:49:55 <ErCiccione[m]> I will look it up
17:50:13 <ErCiccione[m]> .merge+ 1159
17:50:13 <xmr-pr> Added
17:50:21 <sarang> OK, if it's clear enough to non-graphical browsers that it's external, perhaps that's ok
17:50:36 <sarang> Although I've always known "if you have an image, use an `alt` every time"
17:50:52 <sarang> Or something that can be interpreted properly by non-graphical browsers
17:54:06 <ErCiccione[m]> Yeah but that icon is not really an image. Just points out that the link is an external link, it's a visual help that somebody using a screen reader doesn't need
17:54:32 <ErCiccione[m]> anyway, i'll check, it's interesting stuff anyway
17:55:03 <asymptotically> and there's no img element to put the alt text on :(. if we really desperately wanted it maybe it could be next to the link with display:none?
17:56:08 <asymptotically> also til that you can match things with regex like that in css
17:58:47 <ErCiccione[m]> I really don't see how a text would be useful in this case to be honest.
17:59:26 <ErCiccione[m]> regex like that in css <- yeah i didn't know either. Was an interesting thing to learn, still limited capabilities tho, but cool nonetheless :D
18:21:10 <ErCiccione[m]> asymptotically: changed ids to classes, thanks for pointing it out
18:21:24 <ErCiccione[m]> and pushed obviously. the preview should be ready in a couple of minutes
18:27:00 <ErCiccione[m]> .merge+ 1161
18:27:00 <xmr-pr> Added
18:27:04 <ErCiccione[m]> .merges
18:27:04 -xmr-pr- 1117 1159 1160 1161
18:29:30 <ErCiccione[m]> sarang could you give a final review to 1146? the I2P address is not part of it anymore, since it doesn't need https
18:45:04 <asymptotically> just noticed that one of the adblock cosmetic lists i have doesn't like .hangouts-social and hides it
18:45:25 <asymptotically> doesn't like .social-icons*
18:46:28 <binaryFate> ErCiccione[m]:
18:46:33 <binaryFate> LC_CTYPE="en_US.UTF-8"
18:46:34 <binaryFate> LANG="en_US.UTF-8"
18:46:36 <binaryFate> bundle exec jekyll build --source <source> --destination <destination>
18:46:49 <binaryFate> ^ that's the command used
18:47:20 <binaryFate> Thanks for reminder to add nginx conf to repo, I'll try to do next week
18:53:21 <ErCiccione[m]> asymptotically: lol. I guess we could change the name of the class, but at the end the filter is just doing its job, so makes sense to leave things as they are.
18:53:34 <sarang> ErCiccione[m]: 1146 approved
18:54:04 <sarang> Best not to attempt to bypass filters
18:54:14 <sarang> very sleazy
18:54:40 <ErCiccione[m]> Thanks binaryfate. There shouldn't be problems with having an empty baseurl then. Will look for some more info about it anyway.
18:55:39 <ErCiccione[m]> Sarang: thanks and yeah. If people don't want to see social icons we should respect their choice.
18:56:47 <asymptotically> yeah i don't care for facebook or similar, so i hide anything to do with it. i was just looking at the diff showing the buttons and wondering why i couldn't see them, until i remembered to check the ublock logs
18:58:34 <ErCiccione[m]> .merge+ 1146
18:58:34 <xmr-pr> Added
18:59:02 <ErCiccione[m]> .merge+ 1145
18:59:02 <xmr-pr> ...
19:02:33 <ErCiccione[m]> .merges
19:02:33 -xmr-pr- 1117 1145 1146 1159 1160 1161
19:05:08 <sarang> asymptotically: with the filter, does it "fail usefully"?
19:05:17 <sarang> As in, just hides the whole thing, and doesn't display something odd?
19:05:43 <asymptotically> nope, looks normal (just missing facebook/twitter/reddit/...) buttons
19:06:23 <sarang> Cool
19:06:27 <sarang> That seems like reasonable behavior
19:06:52 <sarang> I mean as opposed to display something that isn't clickable, or whatever
19:07:01 <sarang> which would be confusing and off-putting
19:07:21 <sarang> I wonder if I have my uBlock filters on for that domain
19:07:45 <sarang> I do! Default filters (and a bunch of others) don't block the icons
19:08:34 <sarang> Anyone have a non-graphical browser or screen reader to see how the social links appear?
19:08:40 <sarang> There's no tooltip for those
19:08:55 <sarang> At least, nothing that displays on my (graphical) browser
19:10:13 <sarang> Is there a standard way to handle links with no text, like the social buttons?
19:10:15 <asymptotically> sarang: the list is called "Fanboy's Social Annoyances", it comes with ublock origin by default, but disabled
19:10:39 <sarang> Hmm, thought I had that one added; maybe not anymore
19:10:54 <sarang> Ah, I do not
19:11:59 <asymptotically> they are broken in emacsww (quasi-graphical). just empty bulleted lists
19:12:17 <asymptotically> if it had actual images for the social icons, it would show them. but not the css background images
19:12:34 <sarang> Is there something that can be done to make that more accessible?
19:12:53 <asymptotically> https://i.imgur.com/LGoVx6K.png
19:12:55 <ErCiccione[m]> firefox has a new cool tool called "inspect accessibility proprieties", which helps with making a websie more accessible. I will spend some time to inspect getmonero to fix accessibility problems where there are any
19:13:14 <sarang> That would be great
19:14:04 <sarang> Are there tools that could be included with CI to perform any automated accessibility analysis?
19:14:13 <sarang> Having it built in to the workflow would be so cool
19:15:03 <asymptotically> in my (rather limited) experience, these automated tools are only good for a rough first pass. they can tell you if text has poor contrast, or if an image has no alt text, but you really have to go through yourself with a screen reader to make sure that it's usable
19:15:19 <sarang> Sure, but being able to catch obvious stuff automatically seems like a winner
19:17:08 <sarang> Good-but-not-perfect is certainly better than nothing
19:17:08 <asymptotically> well it wouldn't hurt :D