Update rosetta homepages to new homepage version

[StevenDufresne]

The rosetta site homepages are still showing the older version. They were not updated during the initial rollout of the new homepage to limit the scope. It's time to update the rest.

[dd32]

#15 covers the background to why this wasn't initially updated.

[ryelle]

We've had the content parser running for a while, and it's worked fairly well (especially with the updates and tests from #247 & WordPress/wordpress.org#90).

This project is not imported into GlotPress yet, that would need to happen so it could be translated— we should let #polyglots know that this is incoming first, in case there's more feedback on the strings & process.

Then maybe soft-launching with the theme switcher again? So we can get feedback on it in-action? Maybe that's overkill.

I tested wporg-main-2022 on my sandbox to see how it holds up, and mostly it was fine.

My notes from that test (these can become issues if needed, but right now it's just a brain-dump).

• wporg-main-2022 and wporg-parent-2021 will both need to be added to GlotPress
• Do rosetta sites use localized page slugs?
  • Looks like no, but it might affect the template assignment if so.
• For the local pages (those that are specific to the rosetta site, not run through GlotPress), could we just turn on the default redesign page template? (like what the About subpages use)
• Needs to support posts & archives, example on ja.w.org, example on es.w.org
  • The sidebar can be unique to a site, by updating the widgets. How important is this? Can we allow some customization without giving access to the entire Site Editor?
• In-page navigation menus (About, Download)
  • Currently hard-coded to a menu ID on wp.org, won't exist on rosetta site.
  • We could either loose the menu and hardcode the items in the template, then set up a filter like what's run in the global header to swap out the locale URL
  • Use __unstableLocation, and have each rosetta site set a menu to each location. but it's "unstable"
  • Add a custom attribute to mirror ^ but since we set it, it will be stable.
• Need to update links to locale specific
  • Some links in content could be translated in the string
    • Would work for “Get started” on home
    • But not for About page list, hrefs are not part of the list item string (maybe they should be after all)
  • Nav on Download page (below Downlod button)
    • Can handle as part of general nav solution
• Some RTL issues on the About main page, everything else I spot-checked looked good

[ryelle]

Consolidating and updating the notes above, these are the tasks that still need to happen before this can be launched:

• Add theme to GlotPress
• Add theme switcher toggle
• Update archive & single post template to use Local Navigation block
• Fix navigation menus
• Fix RTL issues on About main page
• Fix release table on Download > Releases page (not showing up)
• Coordinate rolling out the new theme

[estelaris]

Do rosetta sites use localized page slugs?
Looks like no, but it might affect the template assignment if so.

Does that mean that rosetta sites will not have localized URLs in the future? Part of the proposal is to localize or translate urls, as in es.wordpress.org/documentacion/articulo.

Or is this perhaps something we can look into in the future?

[tobifjellner]

From a global mentor's perspective, it's much better to not localize URL:s. Especially in non-latin scripts the URL:s become very ugly. At least for "centrally handled content" there is certainly a value in being able to just swap out the locale subdomain and land on the same page on a different locale.
Any content that is manually added by each Rosetta team, obviously, will use whatever slugs suit the needs best. In many cases that may be a phonetic version to the "safe" English alphabet.

[ryelle]

This issue is specifically about the main rosetta sites, the content handled by es.wordpress.org/wp-admin/, ja.wordpress.org/wp-admin/, etc. Current functionality is not changing, that question was just my process of understanding the existing behavior.

Right now this is my approach to making sure the main theme works for Rosetta.

• es.wordpress.org/about/ mirrors the content on wordpress.org/about/, so the page template with the correct source content is applied
• Teams may also have custom pages like es.wordpress.org/colabora/, but this is unique content written in wp-admin, so we can use a general page template
• Teams can have blogs, like es.wordpress.org/news/, and that content is also written in wp-admin, so we need post and archive templates

At least for "centrally handled content" there is certainly a value in being able to just swap out the locale subdomain and land on the same page on a different locale.
Any content that is manually added by each Rosetta team, obviously, will use whatever slugs suit the needs best.

That's how this site and others like the plugin and theme directories work, so I imagine for consistency it would stay that way for other sites too. But that's a discussion for later 🙂

[estelaris]

Thank you @ryelle for explaining, I didn't understand your thought process at the beginning.