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.

[ryelle]

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

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

[tobifjellner]

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

[StevenDufresne]

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]

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]

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

[ryelle]

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]

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]

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]

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]

@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]

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]

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]

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.

[naokomc]

This is an interesting discussion indeed, and it helps all of us understand design localization in the real world.

If the Meta Team is comfortable to the idea, allowing certain Rosetta sites to make minimal style adjustments via the Site Editor would be a great step. This might be limited to CJK (Chinese, Japanese, Korean) languages or those who have requested it with a valid reason, to prevent any unintended issues against design integrity.

[megane9988]

Hi everyone. This is an interesting discussion.
I am base in Kobe Japan.

I created a compared image.
What causes the impression of the original design to deviate from the original design when translated? I hope this will help you confirm that.

The comparisons are https://ja.wordpress.org/?new-theme=1 and #266 (comment).

About 'unintentional line break', it's difficult to understand if you don't understand Japanese.

For example,

WordPres
s

or

Gutenberg Plu
gin

That's what it feels like.

First of all, I think this new design is really nice.

And I think it would be good if we could create the same image as much as possible in languages ​​with alphabets such as Japanese and Other multibyte language.

I am by no means denying existing designs, so let me reiterate that point.

[nukaga]

@miminari, @megane9988 thanks for the detailed explanation! I found that very clear!

@fcoveram And thank you for trying to understand our culture.

I would like to support miminari's suggestion below.

For example, how about adding a process to apply CSS only when Japanese () is displayed?

We do not want to change everything, so as @naokomc wrote,

This might be limited to CJK (Chinese, Japanese, Korean) languages or those who have requested it with a valid reason, to prevent any unintended issues against design integrity.

I think it is also important.

[StevenDufresne]

The think use case has been proven successfully. It isn't clear with block theming how to do this intelligently. I wonder if we can leverage style variations (or something custom but similar).... Open to ideas!

[t-hamano]

I may not understand the problem accurately, but I would like to suggest the following as an idea for adjusting CSS for each locale.

Note: This code has not been tested and is just a sample of the approach.

Enable customization with CSS and PHP code for each locale

First, create a locale directory under the theme directory. Then, load style sheets and custom PHP code for each locale.

source/wp-content/themes/wporg-main-2022/functions.php

function enqueue_assets() {
	// ...

	// get the current locale.
	$locale = get_locale();

	// Load stylesheet and php code according to locale
	if ( 'en_US' !== $locale ) {
		// Path to the stylesheet for that language in the `locale` directory
		$stylesheet_path = get_stylesheet_directory_uri() . '/locale/' . $locale . 'style.css';
		// Load stylesheet if file exists
		if ( file_exists( $stylesheet_path ) ) {
			wp_enqueue_style( 'wporg-main-2022-style-' . $ja, $stylesheet_path );
		}

		// Path to the php file for that language in the `locale` directory
		$functions_path = get_stylesheet_directory_uri() . '/locale/' . $locale . 'functions.php';
		// Load php file if file exists
		if ( file_exists( $functions_path ) ) {
			require_once $functions_path;
		}
	}

	// ...
}

Add stylesheets for locales

This stylesheet will probably look something like this: Unfortunately, we may need to use important a lot.

source/wp-content/themes/wporg-main-2022/locale/ja/style.css

.wp-block-wporg-random-heading.has-heading-cta-font-size {
	font-size: 30px !important;
}

Add custom PHP code

PHP files can be used for various purposes, such as the following.

source/wp-content/themes/wporg-main-2022/locale/ja/functions.php

// Override settings in a theme's theme.json
function ja_override_theme_json() {
	$new_data = array(
		'version'  => 2,
		'styles'   => array(
			'typography' => array(
				'fontFamily' => 'font-family-for-japanese'
			),
		),
		'settings' => array(
			"custom" => array(
				"ja-something-key" => 1,
			)
		),
	);
	return $theme_json->update_with( $new_data );
}
add_filter( 'wp_theme_json_data_theme', 'ja_override_theme_json' );

function ja_override_styles() {
	// Remove header and footer styles
	wp_deregister_style( 'wporg-global-header-footer' );

	// Enqueue a custom CSS file for that locale
	wp_enqueue_style(
		'wporg-global-header-footer-ja',
		get_stylesheet_directory_uri() . '/locale/wporg-global-header-footer.css',
		array(),
		get_stylesheet_directory_uri() . '/locale/wporg-global-header-footer.css',
	);
}
add_action( 'after_setup_theme', 'ja_override_styles' );

[fcoveram]

Thanks @megane9988 for putting the style discussion in a visual comparison. Very clear. And thanks @t-hamano for jumping in and suggesting a solution.

[t-hamano]

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:

[StevenDufresne]

I wonder if we can do it with style variations.

[t-hamano]

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]

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]

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]

@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]

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]

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

• Français - https://fr.wordpress.org
• Deutsch - https://de.wordpress.org
• Suomi - https://fi.wordpress.org
• Català - https://ca.wordpress.org
• فارسی - https://fa.wordpress.org
• China 简体中文 - https://cn.wordpress.org
• España - https://es.wordpress.org
• Italia - https://it.wordpress.org
• Svenska - https://sv.wordpress.org
• Shqipëri - https://sq.wordpress.org
• Venezuela - https://ve.wordpress.org
• Galego - https://gl.wordpress.org
• English (UK) - https://en-gb.wordpress.org
• नेपाली - https://ne.wordpress.org

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]

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

[tobifjellner]

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

[ryelle]

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]

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]

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/:

https://wordpress.org/about/:

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

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

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