Why do we enforce a baseurl which is the same as the url?

I remember rehrar adding it long ago saying that it was needed to build properly? Why was that the case?

Our baseurl is set wrong and causes a bunch of issues

binaryfate: what's the command you use to buil the website?

Oh, i think i understood. Looks like the multilingual plugin needs it set in a weird way, which is not it's original purpose.

<rehrar> Erciccione remember that this whole thing is held together by duct tape and string.

but why?

<rehrar> Because the multilingual thing was horrific to work with as I recall.

<rehrar> Everything broke if it was not just so.

<rehrar> I reached out to the creators of jelyll and the plug-in at the time and didn't receive a response.

<rehrar> And I'm a designer, not a Ruby/liquid specialist, so I found my workarounds.

Yeah i understand

<rehrar> If you can solve this thing then I will sing your praises.

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

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

and btw the multilingual plugin we use it's not maintained anymore

they are looking for volunteers willing to maintain it

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

Yeah we have to stop using baseurl the way we do.

or it will break things foreva

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

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: byparker.com/img/what-is-a-baseurl.jpg. Problem is that jekyll and all related plugins obviously use the correct formatting

which means we will always have incompatibilities with plugins and other jekyll's narive structures

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

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

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

ErCiccione[m]: is there another plugin that we can swap to that is maintained?

as I'm guessing it's not currently in our capacity to maintain this thing

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.

link for me to look?

if you have the time

at your convenience

I have to look for it, i honestly don't remember even the name of the plugin

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

What's supposed to be different with this PR? monero-project/monero-site #1145/files

e.g. on the Hangouts page, the top social icons appear identical

Also, have reviewed some other PRs

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)

if you browse the website, you'll see all external links have the icon now

see the MRL page for example

Agreed with the other commenter who noted that `id` should be `class`

yep. Didn't think about that, will change it

Are external links distinguished for other types of browsers, like screen readers?

I noticed e.g. that there's no hover text or anything to clearly indicate external other than the little superscript icon

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.

IMO it would be nice UX to have hover text indicating "external link" or something

And perhaps this would also help something like a screen reader or other browser types

If the standard is "not great for accessibility" then let's lead past the standard

Oh wait, maybe just a proper `alt` on the image would do it

Right now it's an image with no `alt`, which AIUI is bad for accessibility

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.

Anyway, i will look it up to see what's the best course of action in this case

Also, that icon is not an image

Should the image not still have an `alt`?

it's an SVG, no?

Or am I misreading

oh sorry, i confuded myself with the other icon, which has a tooltip (the info button)

the external link icon is an svg, yes

I don't mean to sound pedantic on this, but I think it's important to address accessibility from the start, whenever possible

it's the right thing to do

If it isn't an accessibility problem, great

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.

I will look it up

.merge+ 1159

Added

OK, if it's clear enough to non-graphical browsers that it's external, perhaps that's ok

Although I've always known "if you have an image, use an `alt` every time"

Or something that can be interpreted properly by non-graphical browsers

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

anyway, i'll check, it's interesting stuff anyway

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?

also til that you can match things with regex like that in css

I really don't see how a text would be useful in this case to be honest.

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

asymptotically: changed ids to classes, thanks for pointing it out

and pushed obviously. the preview should be ready in a couple of minutes

.merge+ 1161

Added

.merges

sarang could you give a final review to 1146? the I2P address is not part of it anymore, since it doesn't need https

just noticed that one of the adblock cosmetic lists i have doesn't like .hangouts-social and hides it

doesn't like .social-icons*

ErCiccione[m]:

LC_CTYPE="en_US.UTF-8"

LANG="en_US.UTF-8"

bundle exec jekyll build --source <source> --destination <destination>

^ that's the command used

Thanks for reminder to add nginx conf to repo, I'll try to do next week

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.

ErCiccione[m]: 1146 approved

Best not to attempt to bypass filters

very sleazy

Thanks binaryfate. There shouldn't be problems with having an empty baseurl then. Will look for some more info about it anyway.

Sarang: thanks and yeah. If people don't want to see social icons we should respect their choice.

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

.merge+ 1146

Added

.merge+ 1145

...

.merges

asymptotically: with the filter, does it "fail usefully"?

As in, just hides the whole thing, and doesn't display something odd?

nope, looks normal (just missing facebook/twitter/reddit/...) buttons

Cool

That seems like reasonable behavior

I mean as opposed to display something that isn't clickable, or whatever

which would be confusing and off-putting

I wonder if I have my uBlock filters on for that domain

I do! Default filters (and a bunch of others) don't block the icons

Anyone have a non-graphical browser or screen reader to see how the social links appear?

There's no tooltip for those

At least, nothing that displays on my (graphical) browser

Is there a standard way to handle links with no text, like the social buttons?

sarang: the list is called "Fanboy's Social Annoyances", it comes with ublock origin by default, but disabled

Hmm, thought I had that one added; maybe not anymore

Ah, I do not

they are broken in emacsww (quasi-graphical). just empty bulleted lists

if it had actual images for the social icons, it would show them. but not the css background images

Is there something that can be done to make that more accessible?

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

That would be great

Are there tools that could be included with CI to perform any automated accessibility analysis?

Having it built in to the workflow would be so cool

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

Sure, but being able to catch obvious stuff automatically seems like a winner

Good-but-not-perfect is certainly better than nothing

well it wouldn't hurt :D