HOC: Update to 2020 dates - #35735
#35735HOC: Update to 2020 dates#35735
Conversation
breville
left a comment
There was a problem hiding this comment.
Really great work.
I guess one downside is that we will lose the existing translations until new ones come in?
| id = "europe_#{id}" | ||
| end | ||
|
|
||
| return HOC_I18N[language][id] || HOC_I18N['en'][id] |
There was a problem hiding this comment.
What does HOC_COUNTRIES vs. HOC_I18N represent?
There was a problem hiding this comment.
HOC_COUNTRIES is the parsed countries.json file as an object. HOC_I18N is all the *.yml files (per language) for the hour of code translation variables--so the new variables I put in en.yml will be in HOC_I18N
That is true, although with so many switching to the non-default hour of code week it would have been hard to maintain the existing translations (a lot of switches from December to October). |
|
Update on this PR: it turns out Latin America and Africa have different date ranges, so what was originally 3 sets of variables is now 4. The description has been updated with the new dates. |
| id = 'campaign_date_full_year' | ||
| end | ||
|
|
||
| if %w(latam europe africa).include? type |
There was a problem hiding this comment.
Is it worth doing the opposite of this? i.e. unless type == 'default'. I feel like it's possible that we add another set of dates and then we would only have to edit countries.json and en.yml
There was a problem hiding this comment.
that's fair, I was worried about the likelihood of someone putting an incorrect type in there, in which case we would want to fall back to default instead of using an id that doesn't exist
That's true but given that the dates are changing, this feels like when we want to lose the translations so there isn't incorrect info on the site. |
Update our HOC dates for the 2020 events. This is a re-haul of how we previously stored dates, which was in a single json file we updated manually each year for all countries. This should make future year updates much easier.
There are 4 sets of dates now: Latin America has one date (called this
latam), Europe has one date (called thiseurope), Africa has one date (called thisafrica) and everyone else (US/Canada, Asia, Australia/New Zealand) use the December date (called thisdefault). We still havecountries.jsonbut instead of storing the date translations it stores which date type the country uses, along with the language to use. Then we have 3 sets of date variables in the translations file, and pick a date to use depending on the user's country. We already funneled the date translation throughhourofcode_helpers.campaign_date, so I repurposed that method to pick the correct variable and send it back.The dates are:
Latin America: October 1 - December 18
Africa: October 1-31
Europe: October 10-25
Default: December 7-13
Links
Testing story
Validated the dates appear correctly depending on the type of the user's country.
Reviewer Checklist: