michaelkohler / activate-rewrite Goto Github PK

Alignment with CDT is crucial, I'll have a meeting with Lucy, K and Nuke on Friday.

• Check out gh-pages of https://github.com/mozilla/activate.mozilla.community and create a master branch
• Delete content of master branch
• Apply all commits of this repo to the master branch
• Adapt README
• Move issues
• Deprecate this repo and link to normal one

The URL should update to include the new language if the user switches the language in the footer.

We should allow language links such as /en-US/subsite or /es/subsite which then directly switch the language to the requested language. If the language is not available, it should fall back to EN.

According to https://developer.mozilla.org/en-US/docs/Mozilla/Implementing_Pontoon_in_a_Mozilla_website the correct way is:

/locales/{locale_code}/path/to/file.extension

This task can't be done now, we will need to move to the official repo first.

• Decide on initial locales
• Get project listed on Pontoon
• Give permissions to Pontoon on repo
• Remove pseudo ES localizations
• Get admin access on Pontoon to enable new locales
• Define process on when locales are ready to be enabled on the site

Found a couple of bug in webkit view today:

• The header logo is stretched

The language selector at the bottom is not persistent, if you set it to es and go to a en-US link it will stay in Spanish but with the option in en-US.

Also if you refresh the website, it will be in English.

Mostly mobile does not look good in all sizes:

Additionally on mobile the menu does not work at all.

• Do we need to provide an EN-copy/empty locale.ftl for new languages? Do we need to request them or can Pontoon be enabled for all locales and we get what we get?
• If there are new EN strings, do they need to be added the same way to the other locale files or does Pontoon pick them up and offers them for translation? How can we handle language fallback of a single string if we don't add to the other locales ftl files without having fallbacks in the HTML as in https://github.com/projectfluent/fluent.js/blob/master/fluent-react/examples/fallback-sync/src/App.js#L20? If not, is there a way to automatically do the placeholder fallbacks (so we don't need to change the placeholder and the EN string if we change something?)
• If there is a string change, does Pontoon pick it up or do we need to modify the key for it to be picked up?
• What do we need to enable for Pontoon to work?
• Is there anything special to notice when using Pontoon with Fluent?
• Is there a GitHub bot that posts issues once a language has >X% translations?

• Copy will come later
• Button with link to Splash event page

Currently we have the following issue: we have to have placeholders in the JSX files to make sure we show the EN text if loading the localization file (or something along the way) fails. This means that any EN update needs to be in two places: 1) placeholder in JSX, 2) en-US.ftl file.

It would be great if we could delete all placeholder texts in the source and have a build step that automatically injects the translations as fallback. This could be rather tough though as this build step would need to understand FTL.

Happy to review PRs and/or answer questions around this if somebody wants to give this a shot :)

I've asked @elioqoshi for an updated logo which fits the new style (same as new Reps logo) and matching the blue we use.

After #40 is merged, a call to https://rewrite.michaelkohler.info/es/eventguide/ will lead to a 404 as GitHub won't find the file as we're using client side routing GitHub doesn't know anything about. There are workarounds for this, will have a look :)

Otherwise we always refresh the page. The problem I currently see is that we need to reorder some stuff as outside of is not allowed.

@Lucyeoh to provide the copy for it.

Currently the footer has some inconsistencies:

• The two borders to separate the logo and the language switcher are not the same
• The Logo and Language switcher are not aligned centered compared to the description
• Footer should always be at the bottom (currently it's not if there is not enough content to fill the height of the screen)
• Better mobile view

When reloading the page we first display the fallback font and then once loaded, Zilla Slab Highlight is shown. This is quite a remarkable flash on the screen and we should try to avoid this.

This depends on #4 as this is solely the container to list all activities on it's dedicated page like on https://activate.mozilla.community/activities/