search

WordPress / wporg-main-2022

A block-based child theme for WordPress.org, plus local environment
65 stars 26 forks source link

Update rosetta homepages to new homepage version #266

Closed StevenDufresne closed 2 months ago

StevenDufresne commented 1 year ago

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 commented 1 year ago

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

ryelle commented 1 year ago

We've had the content parser running for a while, and it's worked fairly well (especially with the updates and tests from https://github.com/WordPress/wporg-main-2022/pull/247 & https://github.com/WordPress/wordpress.org/pull/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).

ryelle commented 1 year ago

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

estelaris commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

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 commented 1 year ago

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

ryelle commented 1 year ago

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 commented 1 year ago

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

StevenDufresne commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/WordPress/wporg-parent-2021/commit/a93b95a11ba1e4a49b89bfe080548c9082dce512.

ryelle commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

miminari commented 11 months ago

@ryelle cc. @naokomc Hi, I have a suggestion about localization. Simply switching to Japanese will result in a broken design. To avoid this, I and @nukaga created a design adjusted for Japanese. https://www.figma.com/file/8emLGbEzKE7egQdKFysOkX/Home-%26-Download-Pages-(Ja)?type=design&node-id=3586-630&mode=design&t=6ArawEokD75Or2wI-4

I want to discuss how to implement this to "ja.wordpress.org".

For example, how about adding a process to apply CSS only when Japanese (<html lang="ja">) is displayed?

StevenDufresne commented 10 months ago

Hi @miminari. When I click that link I just see the cover page. Can you share the images directly in GitHub for those who don't have access to figma.

I am personally not content with the way wordpress.org varies wildly between languages. It isn't an expected behavior. As a new user, when I show up on the homepage and click to see it in my language, it should look and feel the same, but just in my language. I think we've fallen into a habit of building for ourselves. I would like to see us converge more on the same design, as opposed to making language-specific changes. With that being said, I don't want that to deter experimentation, so please share your designs!

fcoveram commented 10 months ago

I opened the Figma file but don't see any mockup in Japanese. Curious to learn review and learn from how to design for other languages.

nukaga commented 10 months ago

@StevenDufresne @fcoveram Thanks for your comments, I looked at the history of Figma and found the Japanese version of the design in the October 5, 10:29 AM edition. https://www.figma.com/file/8emLGbEzKE7egQdKFysOkX/Home-%26-Download-Pages-(Ja)?type=design&version-id=4278006363&node-id=970-9814&mode=design&viewport=263%2C1182%2C0.34&t=h466ozkrbu6WY5ZV-0 I'll check with @miminari to see if someone may have sorted it out!

The Japanese design hasn't changed a huge amount, just adjusted the font size, line spacing, line breaks, etc. so that it doesn't look weird. The font size in English is too large for Japanese, so I've adjusted the font size, line spacing, line breaks, etc.

miminari commented 10 months ago

@StevenDufresne @fcoveram Thank you for checking our design. I'm afraid I made a mistake and the design was lost once. So please check it again: https://www.figma.com/file/8emLGbEzKE7egQdKFysOkX/Home-%26-Download-Pages-(Ja)?type=design&node-id=3586-630&mode=design&t=kYIfJmWkPVXOftB2-4

Junko is right, and I would further add.

For example...

  1. we are not used to using italics. Italics are used relatively rarely in Japanese text. there is no cultural background for the use of italics in Japanese text, and there is no defined method for its use. When needed in a translation, bold is often substituted.
  2. A larger line-height in the body than the English text is often necessary to guarantee readability.
  3. Even if the font size is the same numerical value as Latin, it often seems more significant in Japanese. Therefore, we are used to adjusting the font size for the same design for localization.

Therefore, I often feel disappointed when I see sites where only the text has been replaced with Japanese for multilingualization. What would have been a very nice and cool design if it were Latin instantly becomes weird. If it's just a document, no problem, but if it's a branding page, the result would be painful. It is like declaring that you are not interested in the Japanese market or culture.

I only know Japanese culture, but I suspect the same thing may be true for other non-Latin languages.

miminari commented 10 months ago

@StevenDufresne

Can you share the images directly in GitHub for those who don't have access to figma.

Sorry, I missed this message.

I share the design image file here: Japanese version

fcoveram commented 10 months ago

Awesome. Thanks for sharing this design. I only know the Latin alphabet so this work is very fruitful and inspiring.

Regarding font sizes, I don't see any copy inconsistency with the English version. My only doubt is whether we need to add a sentence in Japanese for the "Get started". In other languages the same text can be long, but it could also be a good opportunity to try a fluid size based on the viewport.

I envision implementing a system where font-size, line-height and other CSS specs are documented per language, if I understand correctly how it works. If that is the way to approach it, it would be great to include that font system in the site's Design Library.

I can't add it as I only have view permissions to the file shared, but I'm happy doing it. Or if you @miminari and @nukaga want to edit the Design Library file, please you are more than welcome.

nukaga commented 10 months ago

@fcoveram Thank you very much. Japanese has "Kanji" characters and is more complex, so Japanese is displayed larger than Japanese even with the same font size.

I discussed the "Get Started" part with mimi. We are trying to take the approach of adding Japanese words to English words, because it is not cool to put English words directly into Japanese, and some people may not understand the meaning if only English words are used. This approach (English + Japanese) is often used on Japanese sites to make them look better.

We feel that the issue of language-specific CSS is not limited to Japanese. I was thinking it would be nice if we could include design adjustments for each language in the Design Library file, but would that be a lot of work?

We believe that eventually other pages (such as About) will need to be adjusted for the Japanese version.

In any case, I think it would be a good idea to have @fcoveram have the authority to edit the Figma of the Japanese version of the design first. @miminari what do you think? I am concerned that it is your personal account that is the owner.

fcoveram commented 10 months ago

I was thinking it would be nice if we could include design adjustments for each language in the Design Library file, but would that be a lot of work?

If I understand localization correctly, the design documentation and implementation should be per alphabet rather than per language. The current spec for Latin should work for several languages (English, Spanish, Italian, and so on). This does not minimize the big effort it carries, but the improvement can be incremental as collaborators jump in.

We are trying to take the approach of adding Japanese words to English words, because it is not cool to put English words directly into Japanese, and some people may not understand the meaning if only English words are used. This approach (English + Japanese) is often used on Japanese sites to make them look better.

I understand. I meant to replace the word "Get started" in English with the Japanese translation, which seems to be "今すぐ始める". But if you think that adding a Japanese sentence below the English one is better, let's do that.

I think it would be a good idea to have @fcoveram have the authority to edit the Figma of the Japanese version of the design first. @miminari what do you think? I am concerned that it is your personal account that is the owner.

This can work. Then I would move the file into the project folder and give view access to anyone. @miminari already has edit access to the WordPress.org team, and we can request one for you @nukaga if you want.

tobifjellner commented 10 months ago

We could go different ways here:

  1. Create additional versions of the theme for various language groups.
  2. We can hardcode possible differences directly into the theme and then use a few selection parameters via the translation system to pick the right version. (In my view, this is a relatively clean and flexible approach.)
  3. The theme can inject some small design differences depending on which language is used. (The "old" Rosetta theme uses this solution in a few places, to pick the right font, etc.)
  4. We can "outsource" several design decisions to the translation interface. But that's a risky way to go. Troubleshooting may become very tough.
miminari commented 10 months ago

@fcoveram cc @nukaga Thanks for the review!

Junko has a good point, and I'll try to add to it. I thought of a sentence to explain it to you, but the more I thought about it, the more I felt that we are dealing with troublesome letters 😆. Thank you so much for your concern.

Regarding font sizes

In Japanese, we often mixed Japanese typography (Kanji, Hiragana, Katakana) with Latin typography, and it is common to lower the Japanese characters by 1-2 points (This gap is also larger for larger font sizes). Currently, it is technically difficult to do this in the body of a website, but it is sometimes done to achieve a beautiful balance in titles and headings.

We are attempting to do the same with this title"WordPress:
自由を手に入れよう".

In this design, WordPress: is 100px, but "自由を手に入れよう" is 96px.

If we set every typo to 120px as original design, we get the following: スクリーンショット 2023-11-06 21 53 27

For those who can read Japanese, the text seems too large for the design in this state.

Additionally, there is the problem of line break positioning. Japanese does not necessarily break lines at word breaks because Japanese basically does not contain spaces. Therefore, the typography handled in these keywords and statements often adjusts the line break position.

for the "Get started"

At first, Junko and I tried to create the following design: スクリーンショット 2023-11-06 22 08 22

The literal translation of "Get Started" may be "始める," "はじめよう" or "スタート". We decided to use "今すぐ始める" because it is too short for the design here and the meaning is too straightforward, but "今すぐ始める" does not include the imperative or inviting meaning. Also, the letter '始' in the sans serif pair is a bit difficult to recognize when displayed in large size and is prone to gestalt collapse. Therefore, we replaced it with hiragana, but this time, there were too many hiragana characters this time there were too many hiragana characters, making it difficult to read. The sentences use many hiragana, which is a little strange.

Then, we concluded this is the kind of wording that is not used for CTAs in Japanese, and it is a design that is only possible because it is in English.In such cases, if the policy is to keep the design as unchanged as possible, a Japanese translation is usually added as a supplementary character.

This can work. Then I would move the file into the project folder and give view access to anyone. @miminari already has edit access to the WordPress.org team, and we can request one for you @nukaga if you want.

Thanks for the suggestion. Yes, if it is not a problem, I will move the file to the WordPress official Figma team.

fcoveram commented 10 months ago

Very insightful information. Thanks for the thorough description.

Based on @tobifjellner suggestions, I'm drawn to follow point 1.

Hardcode in point 2 sounds easy to implement and addresses the cases explained above, but troublesome in the long term for other alphabets. Adding theme versions to set font styles per language sounds the cleanest and most consistent way.

For the example described above, body size could be 16px for English and 14px for Japanese. Plus other specs changes like kerning and line-heights. But setting a size for the word WordPress and another for the rest of the sentence might be undoable. In addition to that, I don't know how to handle line breaks and new texts as the "Get Started" situation where its Japanese version is below the English one.

I would like to hear what you think @jasmussen, but as more as I think about the next steps, I lean toward developing a long-term solution. I'm with @StevenDufresne when he says that changing language should look and feel the same.

jasmussen commented 10 months ago

Great discussions all around, thank you for the careful attention to detail.

I think we ultimately will have an opportunity in the fact that the homepage is now a block editor page that technically could make it more easy to edit locally, give or take some customized and tailormade blocks.

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.

I say this also because I sense a light visual homepage refresh is likely going to come into view in the near future. As it tells a holistic story of WordPress, it is ultimately a single "summary" of the entire website, that provides you with entry points in the various sections. Showcase was just redesigned, and that section of the homepage is already being refreshed. Hosting could use a refresh soon, and many other sections of the website need visual updates that will likely affect what can be told as a story on the homepage. Having it be in a block editor with more easily updateable patterns is likely going to benefit such iteration.

miminari commented 10 months ago

@fcoveram Thanks for trying to understand my explanation, even though it's not easy to understand.

For the example described above, body size could be 16px for English and 14px for Japanese. Plus other specs changes like kerning and line-heights. But setting a size for the word WordPress and another for the rest of the sentence might be undoable. In addition to that, I don't know how to handle line breaks and new texts as the "Get Started" situation, where its Japanese version is below the English one.

Sorry for the lack of explanation. Typographical mixing is a mainstream story mainly in print and is still difficult to apply in the text of the Web. The same font size will feel different in size when it is Latin and Japanese. Therefore, simply changing the body size is not the same as adjusting the font size.

The two extreme examples above are written out to illustrate how tedious Japanese-language conversion can be.

Of course, as you said, we would like to find the point where we can optimize the localization without too much effort and without feeling uncomfortable.

What I really want to tell you, however, is that simply switching to Japanese on a site that has been designed so well will be quite unsightly in Japanese.

Multilingualization and localization are two different things.

In fact, it is a very time-consuming task to keep the impression of the original design in localization.

@jasmussen

As it tells a holistic story of WordPress, it is ultimately a single "summary" of the entire website, that provides you with entry points in the various sections.

Yes, I agree this 100%. This page is a very important page that gives an impression of WordPress, so we want to localize it as much as possible, keeping the impression of the original design. Conversely, simply switching to Japanese as-is will spoil the original design and the impression we want to give.

naokomc commented 10 months ago

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 commented 10 months ago

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 https://github.com/WordPress/wporg-main-2022/issues/266#issuecomment-1794283963.

compare

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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 9 months ago

I wonder if we can do it with style variations.

t-hamano commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

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 https://github.com/WordPress/wporg-parent-2021/pull/120. I also already merged a PR to add CSS overrides, with a few fixes for the Japanese About page (https://github.com/WordPress/wporg-main-2022/pull/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 commented 8 months ago

@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 commented 8 months ago

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 commented 5 months ago

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 commented 5 months ago

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

tobifjellner commented 5 months ago

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