The events.php (aka: Rankings) page
Given the recent decision to add gender-based filters, I believe this issue deserves a bump
Because of the controversy around this decision, it makes sense to ensure as well as possible, that these filters are only perceived as filters and not as new rankings that come along with records. Since this will come with some design changes (e.g. issue #1919), it might make sense to combine this right away.
One key aspect to consider while doing this could be somehow visually distinguishing "record-affecting filters" (event, region) and "record-neutral filters" (years, show, gender).
I'm working on this, so I'll assign myself the issue! For if someone is curious, here's a sneak peak of what the new page will look like:

I still have to figure out quite a bit of stuff, but I'm happy with the design so far :slightly_smiling_face:
By the way, a small clarification: I'm not adding anything new to the page, just porting the already existing functionalities. I think any other request should go on a different issue.
Slightly unrelated but we should make sure that countries are consistent throughout the website. Korea -> Republic of Korea.
Slightly unrelated but we should make sure that countries are consistent throughout the website. Korea -> Republic of Korea.
Totally agreed! I don't know where/how this has to be fixed though (I'm just getting the name from the database.)
Getting it from the database bypass i18n and the "correct" names of countries, so you should get it from the Country model.
Not sure what model you're using for the results, but you could implement a country method in Result going through the cached countries list:
def country
Country.c_find(countryId)
end
We do something similar for the format, event, and round type id in the resultable concern here.
(however you can't implement the country method in the concern, because InboxResult doesn't have a countryId).
Without this method, Result.country will use the belongs_to association to load some data from the db, but it's bad for two reasons: it's slow compared to just taking the object from the cache (not just a little!), and the name in the db is simply wrong and English only.
If you're using LightResult, you should build it similarly to what is done here, passing a Country object which support i18n.
Actually, I was using <% country = Country.find(row[4]) %>, where row[4] is the countryId that the query returns, and then getting the name as country.name.
Thanks for the explanation though. I still have many things to refine before this being even close to be ready!
Then use Country.c_find(row[4]) and it should be alright :)
Don't use have a huge amount of SQL select emitted in the log when using Country.find?!
Let's continue the country naming discussion over on https://github.com/thewca/worldcubeassociation.org/issues/4389.