Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update rosetta homepages to new homepage version #266

Closed
StevenDufresne opened this issue May 15, 2023 · 56 comments
Closed

Update rosetta homepages to new homepage version #266

StevenDufresne opened this issue May 15, 2023 · 56 comments
Labels
[Component] Theme Templates, patterns, CSS i18n Translations, RTL issues [Type] Enhancement New feature or request

Comments

@StevenDufresne
Copy link
Contributor

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.

@StevenDufresne StevenDufresne added [Component] Theme Templates, patterns, CSS [Type] Enhancement New feature or request labels May 15, 2023
@dd32
Copy link
Member

dd32 commented May 15, 2023

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

@ryelle
Copy link
Contributor

ryelle commented May 15, 2023

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
Copy link
Contributor

ryelle commented Jul 11, 2023

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

ryelle commented Jul 14, 2023

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
Copy link
Member

estelaris commented Jul 14, 2023

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

@ryelle
Copy link
Contributor

ryelle commented Jul 25, 2023

I've deployed a theme switcher so that users who have wp-admin access can view their sites using the new theme. The link is in the middle of the admin bar. You can switch back and forth with it.

Current theme Preview new design
old new

Hopefully this can catch any issues before we launch to everyone :)

@tobifjellner
Copy link
Contributor

Great. Just in time for our weekly meeting! :)

@StevenDufresne
Copy link
Contributor Author

What should we do about pages that don't have translations yet?

Should we add a "help translate this" prompt, wait until they are translated, or just leave it?

@naokomc
Copy link

naokomc commented Jul 26, 2023

Thank you for adding the switcher!
+1 to adding the "help translate this" prompt.

I have a question. Will Rosetta admins have some controls for font size & font family, etc.?

@ocean90
Copy link
Member

ocean90 commented Jul 26, 2023

Looks like the block spacing isn't working properly on pages like https://de.wordpress.org/2023/07/wordpress-6-3-release-candidate-1/

Bildschirmfoto 2023-07-26 um 15 52 36
ryelle added a commit to WordPress/wporg-parent-2021 that referenced this issue Jul 26, 2023
@ryelle
Copy link
Contributor

ryelle commented Jul 26, 2023

Will Rosetta admins have some controls for font size & font family, etc.?

@naokomc That wasn't planned, but if the existing typography doesn't work for a site, I think we could work with @WordPress/meta-design to add some alternatives or add better fallbacks. Is there a site you see a problem on?

For one example, I see that Courier Prime on the About page doesn't work for Vietnamese, but IBM Plex Mono could.

Courier Prime IBM Plex Mono

Looks like the block spacing isn't working properly on pages

@ocean90 Thanks for catching that, I've fixed it in WordPress/wporg-parent-2021@a93b95a.

@ryelle
Copy link
Contributor

ryelle commented Jul 26, 2023

What should we do about pages that don't have translations yet?
Should we add a "help translate this" prompt, wait until they are translated, or just leave it?

I was looking into using translation status as a way to roll out the new theme (so that a site could switch over when X% is translated), but I couldn't figure out how to access that info from the rosetta site side of things. So I'm not sure how we could detect whether a page is translated or not.

We could add a banner across all pages for a set amount of time?

This also ties into the question of how we should launch— should we flip the switch for all sites at once? let individual teams make the call? something else?

@naokomc
Copy link

naokomc commented Jul 27, 2023

For Japanese, @nukaga said she'd be interested in making suggestions. But because of her timing, it will happen later than mid-August. We (ja) don't need to apply the new design until the refined design is implemented. Plus, we still have 280+ strings to translate 😅
https://translate.wordpress.org/projects/meta/wordpress-org/

Generally, I’d assume a good threshold to be 90% translation completion (currently, five locales are 99-100%). Ideally, the home page should also be in good shape.
Polyglots Team could write a P2 post to let folks know that this change is coming would be a good idea to avoid any surprises and give some time to prepare locale managers.

ryelle added a commit that referenced this issue Jul 27, 2023
All pages that are synced use special wrappers to reset the block gap, but normal pages (on rosetta sites) do not. This change enables the default margin between paragraphs and other post content.

See #266, WordPress/wporg-parent-2021@a93b95a
@ryelle
Copy link
Contributor

ryelle commented Jul 27, 2023

Plus, we still have 280+ strings to translate 😅

Yeah, I'm sure many locales are in that position!

Generally, I’d assume a good threshold to be 90% translation completion (currently, five locales are 99-100%). Ideally, the home page should also be in good shape.

That makes sense to me. I was trying to figure out automating the launch, but maybe it would be better to manually enable sites on request (with some deadline, 2-3 months?, when we flip the switch for everyone, so that it's not perpetual work for the devs).

Polyglots Team could write a P2 post to let folks know that this change is coming would be a good idea to avoid any surprises and give some time to prepare locale managers.

Yes, that would be great. Let me know if I can be any help with that 🙂

@tobifjellner
Copy link
Contributor

@ryelle just like you made a "pre-view" available, you could probably add an action for locale managers and editors and GTE's to change the theme for a locale.
Or, if that's tricky, then we could make it a manual process, where locales that feel ready for it can request me, @naokomc or the meta team to change their theme. This would allow locales to celebrate the "inaguration" of the new theme... :)
And then we'll just state a date for "network enabling" of the new theme, around December 1st, or so.
Just like many locales today aren't translated, many locales won't translate these new strings.
If possible, though, I'd suggest that we in the translation project mark all "new theme front-end" strings as prioritized. That would allow locales to first handle the important strings for the switchover.

@ryelle
Copy link
Contributor

ryelle commented Jul 28, 2023

Or, if that's tricky, then we could make it a manual process, where locales that feel ready for it can request me, @naokomc or the meta team to change their theme. This would allow locales to celebrate the "inaguration" of the new theme... :)

If you have the ability to activate themes already, I think I would prefer this route. I just network-enabled the new theme "WordPress.org Main Block Theme, 2022" so it can be activated on sites as needed.

And then we'll just state a date for "network enabling" of the new theme, around December 1st, or so.

That sounds good.

@ryelle
Copy link
Contributor

ryelle commented Jul 28, 2023

So, I think there's not much more for me to do here, at least until more locales are translated and we gather more feedback.

There is one more PR for the translation parser to enable translating link destinations, so that links inside buttons & lists can be localized like the rest of the page content (for example, translating https://wordpress.org/support/forum/installation/ to https://es.wordpress.org/support/forum/instalacion/). That'll introduce a few changes to the strings.

I also noticed a few translation issues when spot-checking some sites, asked about where to report those in slack.

For now, I'll leave this issue open to collect feedback.

@naokomc
Copy link

naokomc commented Aug 9, 2023

Post published:
https://make.wordpress.org/polyglots/2023/08/09/new-wordpress-org-theme-for-your-rosetta-site/

Finish and Swedish are now using the new theme.

@t-hamano
Copy link
Contributor

t-hamano commented Nov 28, 2023

Another idea: If many of the issues discussed here can be solved by simply overwriting CSS, a mu-plugin that allows you to edit CSS for each locale may also be useful.

It will probably look something like this:

css-by-locale

@StevenDufresne
Copy link
Contributor Author

I wonder if we can do it with style variations.

@t-hamano
Copy link
Contributor

I think using style variations means that what we can do is limited to what can be done within theme.json. It is possible to override the main theme.json settings/styles, etc., but other styles cannot be overwritten via theme.json.

For example, this stylesheet has a large number of styles defined. To override this, we need a way to write CSS directly.

Strictly speaking, CSS can also be written in theme.json. However, it will be very difficult to see, for example:

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"styles": {
		"css": ".wporg-about-section-heading {...}, .wporg-about-section-heading .wporg-about-section-mission {...}"
	}
}
@ryelle
Copy link
Contributor

ryelle commented Jan 8, 2024

To that end, I'm drawn to the idea that localized homepages are also just block editor pages, ideally with the opportunity to start with a copy of the english version and then simply localize them.

Currently, this is not possible, and I'm not sure we should change that. Once the pages are edited in the Site Editor, they'd loose the connection to the patterns/templates, and would not receive any of the English string updates (it would also disconnect the process from GlotPress, which was important to the translators). This would also allow too much customization, IMO — we do still want the localized sites to match the main site.

I wonder if we can do it with style variations.

I think not in the UI for the same reason as above, but maybe we could do something with variations/theme.json (probably will need to custom code something, given how the parent/child theme.jsons already needed a workaround).

We've defined some font settings for the parent theme, they can be found here. For example, the big "WordPress:" headline is the "CTA Heading" at 120px, but a "ja-variation" could set that to 96px. And so on for other headings & body font size, line-height, and even font family if needed.

Customizing the parent theme would be the easiest and future-friendliest, because it would cascade to other pages, like the About subpages or future sections like Hosting & the theme/plugin directories.

Hopefully that would fix the worst typography issues, but we could support locale/site-specific CSS if needed. I'm inclined to something like @t-hamano's suggestion here where the locale team can provide a stylesheet that lives in this repo to be loaded on that locale's site.

@ryelle
Copy link
Contributor

ryelle commented Jan 17, 2024

I've added a method for individual sites to have custom values, and added some of the suggested font sizes for Japanese — there are some before and after screenshots on the PR WordPress/wporg-parent-2021#120. I also already merged a PR to add CSS overrides, with a few fixes for the Japanese About page (#380).

So you can change things like font sizes globally (using a theme.json-ish structure), or make individual tweaks to pages (using CSS).

As I mentioned in that PR, I haven't added a UI for teams to manage this, so any changes will require an issue or PR on this repo.

How does that sound to everyone?

@t-hamano
Copy link
Contributor

@ryelle Thanks for the PR!

Just to confirm, by merging those two PRs, the localized site will not be forced to switch to the new version, right?

@ryelle
Copy link
Contributor

ryelle commented Jan 18, 2024

That's correct, it would still be your choice when to switch to the new design.

At some point, we will want to switch everyone over, as the older theme is not getting the same updates as the new theme (for example, the State of the Word banner). But I'd like to see more locales opting-in successfully first.

@ryelle ryelle assigned ryelle and unassigned ryelle Mar 11, 2024
@ryelle
Copy link
Contributor

ryelle commented Apr 2, 2024

So far the theme has been activated on just 14 sites.

Is there anything meta could do to encourage more teams to opt-in? Are other teams finding issues that prevent them from using the new theme? cc @naokomc @tobifjellner

@tobifjellner
Copy link
Contributor

@ryelle
Yeah. Let's decide a date and communicate it.
Around July 1?

@tobifjellner
Copy link
Contributor

Is there any way to block accidental changes via Site Editor?

@ryelle
Copy link
Contributor

ryelle commented Apr 2, 2024

Yeah. Let's decide a date and communicate it. Around July 1?

Works for me.

Is there any way to block accidental changes via Site Editor?

I deployed a change today that removes the Site Editor links from the admin bar & admin menu. It doesn't block access entirely, but hopefully that will cut down on people trying to customize things.

@naokomc
Copy link

naokomc commented Apr 5, 2024

The Japanese team is working on a few minor adjustments before they are ready.
I just talked to @nukaga and she said they should be ready by July (and aware that is the deadline).

@devhaozi
Copy link

devhaozi commented Apr 5, 2024

Hello, this is the zh_CN polyglot team. We switched to new theme a few days ago. Currently, we mainly find that the spacing of multi-line titles is too small, for example:

https://cn.wordpress.org/about/:
image

https://wordpress.org/about/:
image

https://cn.wordpress.org/download/releases/6-5/:
image

https://wordpress.org/download/releases/6-5/:
image

@ryelle Can you help optimize this, just adjust it like japanese?

@t-hamano
Copy link
Contributor

t-hamano commented Jun 15, 2024

To move this issue forward, I would like to share the progress I understand regarding the Japanese locale. There are the following discussions and PRs:

Personally, I don't think it's necessary to solve all these tasks before migrating to the new homepage version.

I would be happy to discuss and come to a consensus on how far we should achieve before moving to a new homepage version in the Japanese locale, what we should do in non-Japanese locales, etc.

@nukaga
Copy link

nukaga commented Jun 17, 2024

Personally, I don't think it's necessary to solve all these tasks before migrating to the new homepage version.

I agree with this.
Adjustments can be made after the transition to the new design. I thought the original renewal design seemed to need a lot of adjustment in Japanese, but I don't think the current design needs that many.

@ryelle
Copy link
Contributor

ryelle commented Jul 1, 2024

All Rosetta sites have now been updated to the new themes. If there are any problems on specific sites, please open a new issue.

Thanks everyone for all your feedback & working together to get these sites updated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Component] Theme Templates, patterns, CSS i18n Translations, RTL issues [Type] Enhancement New feature or request