i18n: Update textdomain for Event Countdown, Timeline and Blog Posts block

[mkaz]

Changes proposed in this Pull Request

Updates were needed for Internationalization of Event Countdown, Timeline and Blog Posts blocks. This PR therefore moves the source for the Event Countdown and Timeline blocks into the FSE plugin and makes the updates to i18n, including the "full-site-editing" text-domain and add to missing strings.

The goals for FSE plugin changed so now it makes sense just to keep the source and blocks together here.

The two blocks were integrated into the build step, adding the proper package scripts. Building and testing is the same as any other FSE blocks.

Testing instructions

There is no intended functional change, for the two blocks, beyond including the source in the repo and the ability to translate as expected.

A full test to make sure nothing changed.

1. Create a post using the Event Countdown and Timeline block prior to apply the change.
2. Apply the change.
3. Test you can open, edit, and view the previous blocks
4. Test you can create, edit, and view new blocks

Tests on WordPress.com can be carried out with D39116-code.

[matticbot]

Test live: https://calypso.live/?branch=add/wpcom-blocks-src

[akirk]

Thank you very much for this! After figuring out how to generate the dist directories (run npm run build:jetpack-timeline and npm run build:event-countdown-block) I've been able to test this with D39116-code on WordPress.com and filled in the gaps that I also committed here.

After merging this, will you create a new full-site-editing release on .org so that the changes will be available on Atomic? This will allow us to get the newly added strings translated and get them back into a language pack.

[retrofox]

Hi, there.
Just FYI, the blog posts block (BPB) is a block that comes from the Newspack plugin. Basically, all files in newspack-homepage-articles folder are synced from the Newspack repository through a bin script every time that it updates the Newspack plugin version.
It means that in the next updates these changes would be discarded. Here more information.

[akirk]

Thanks for the pointer. This means that we have a textdomain problem here, though. Are we planning to publish the newspack-blocks in the .org plugin directory?

[retrofox]

Are we planning to publish the newspack-blocks in the .org plugin directory?

Honestly, I don't know. We could move this question to @jeffersonrabb

[simison]

Basically, all files in newspack-homepage-articles folder are synced from the Newspack repository through a bin script every time that it updates the Newspack plugin version.
It means that in the next updates these changes would be discarded.

Here's an alternative method I'm suggesting for pulling in Newspack block: #39196 — tho not sure if it's easier or harder to plug i18n considerations into that method. It would definitely make updates easier/more fun.

[simison]

It would be cool to switch to Sentence case from Title Case before we send these for the translation since that's the direction core is also taking.

[simison]

sed ing is fine and fast — did you also consider running wp-textdomain here? I'm assuming not worth for one file?

Would be great if it would handle .js files too, tho.

[retrofox]

should we remove the part of the syncing files on this process, in favor of #39196?

[akirk]

I talked to @simison and he said his changes are independent of that sed above.

@simison, I agree but as of now wp-textdomain only supports PHP.

[jeffersonrabb]

Are we planning to publish the newspack-blocks in the .org plugin directory?

@akirk as of now, no plans to publish to .org.

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[mkaz]

Rebased and all issues addressed (and tests properly kicked).
This should be ready to go.

[noahtallen]

From the FSE plugin point of view, this is looking good!

• ✅ Added timeline and countdown blocks to a page on wpcom before syncing. Verified it looked good in editor and on front end.
• ✅ Pulled changes locally and ran the fse plugin dev & sync command
• ✅ Reloaded the editor on wpcom and verified that I can still make changes to those two blocks which are reflected on the front end. (and verified that I'm loading the dev version of the plugin.)

I did leave a comment D39116-code regarding the deploy step. I'm not sure if the diff was just for testing or if it was also meant to be merged there. Just want to make sure things will work well for the

P.S. once #39528 and D39062-code are merged, a link to a wpcom diff will be added to the PR if it affects FSE plugin files! It'll be nice for testing changes like this without having to do manual syncs :)

[akirk]

@noahtallen I was unaware of the procedure, thanks for the explanation on the Diff! I bumped the version here but then realized that this will be done separately a little later. So I guess this means that this PR can just be merged and will be shipped with the next iteration and we'll close D39116-code and get the changes online via the "normal procedure."

[noahtallen]

So I guess this means that this PR can just be merged and will be shipped with the next iteration and we'll close D39116-code and get the changes online via the "normal procedure."

If that works for you, yes! We're currently doing updates ad-hoc. Feel free to start the process if the FG page makes sense to you :)

[noahtallen]

Though I will say that the update process will only affect the "wp-content/plugins/full-site-editing-plugin" directory. So if those other directories in the diff need to be merged, that would also need to happen separately.