Adding SDK POT file generation for Gutenberg blocks.

[zinigor]

Fixes #30048

Changes proposed in this Pull Request

• Adds the babel-plugin-makepot plugin to the extensions folder for Gutenberg blocks. This is needed to be able to translate blocks in third party code.

Testing instructions

• Run the SDK using this command: node bin/sdk-cli.js gutenberg client/gutenberg/extensions/presets/jetpack/ --output-dir /some/folder/you/want/blocks/to/be/put
• See that alongside editor.js and all other files for Gutenberg blocks you have extensions.pot file generated, and it contains strings from the JSX files.

Now that I look at this PR, I can see that there might be a better approach, one that does not add the makepot plugin to everything, but relies on an environment variable (or other switch) that will be set when SDK runs. I'd appreciate any ideas here.

[matticbot]

Test live: https://calypso.live/?branch=add/sdk-gutenberg-pot-generation

[zinigor]

Thanks for the review, @simison ! I have changed the variable name to use camelCase, as well as made the plugin only be used on SDK runs to avoid generating useless POT files when building normally.

[simison]

Even with the comment, I would still prefer the code to tell this story better by renaming the variable something less generic. Not a biggie tho if you decide to leave it like this!

Consider someone who doesn't know anything about SDK reading this line.

Maybe hasSdkOutputDir ?

[simison]

Just noting that I'm observing strings from both beta and production blocks ending up to the same file — suppose that's the goal so that we can get blocks earlier for translating than they're shipped.

Full list of prod + beta blocks:

wp-calypso/client/gutenberg/extensions/presets/jetpack/index.json

Lines 2 to 17 in 3f05571

	"production": [
	"contact-form",
	"map",
	"markdown",
	"publicize",
	"related-posts",
	"shortlinks",
	"simple-payments",
	"subscriptions",
	"tiled-gallery"
	],
	"beta": [
	"mailchimp",
	"giphy",
	"vr"
	]

[simison]

The babel plugin works great! I get the pot file when building Jetpack preset with --output-dir CLI argument.

One thing that doesn't work right now is when running gutenberg command without --output-dir (it's optional arg):

npm run sdk gutenberg ./client/gutenberg/extensions/presets/jetpack/

That would place files in git-ignored folder ./client/gutenberg/extensions/presets/jetpack/build

I get:

ENOENT: no such file or directory, open 'undefined/extensions.pot'

You can build any block in extensions directry this way, not just presets:

npm run sdk gutenberg ./client/gutenberg/extensions/hello-dolly/

Suppose current setup where pot files is built only with --output-dir would serve our goal of just getting the pot-file to Jetpack plugin directory (in which case the command we indeed use is:

npm run sdk gutenberg ./client/gutenberg/extensions/presets/jetpack/ --output-dir=~/jetpack/_inc/blocks

...but since the SDK and gutenberg build command are kinda generic, the behaviour where pot file gets generated sometimes and sometimes not, can be surprising. I'd suggest we generate it always when dealing with gutenberg command. Another option could be generate it only when dealing with presets folder but that might be confusing as well.

That would require setting the CALYPSO_SDK_OUTPUT_DIR from bin/sdk/gutenberg.js, since that's where output gets finally defined like so:

wp-calypso/bin/sdk/gutenberg.js

Line 105 in 3f05571

path: outputDir || path.join( inputDir, 'build' ),

I would also consider having filename something else than "extensions" — maybe just "translations" or the foldername "jetpack" for preset or block name for the rest?

Another aspect is that there is also notifications SDK command which also has output-dir argument: since the CALYPSO_SDK_OUTPUT_DIR sounds pretty generic and is set in bin/sdk-cli.js file, I'd expect it to handle notifications (and any other) build command as well. Since the plugin is gated to extensions folder, it's not the case. I think it's okay if we make this gutenberg extensions specific for now and make it clear by moving CALYPSO_SDK_OUTPUT_DIR to bin/sdk/gutenberg.js — what do you think?

I was also thinking if we should have pot-generation turned on only as opt-in via separate CLI argument, instead of generate on each run. It doesn't seem to slow the build at all and it's nice not to think of CLI arguments, so current way seems good!

[simison]

To express #30303 (comment) in a bit more compact way, how about we move this to bin/sdk/gutenberg.js and change it to:

const output = outputDir || path.join( inputDir, 'build' );
process.env.CALYPSO_SDK_OUTPUT_DIR = output;

[simison]

Another (maybe easier to read since code stays in one place?) way to structure this would be by using lodash.compact:

plugins: compact( [
	outputDir && [
		'@wordpress/babel-plugin-makepot',
		{
        ...
        }
	],
	[
		'@wordpress/import-jsx-pragma',
		{
			scopeVariable: 'createElement',
			source: '@wordpress/element',
			isDefault: false,
		},
	],
	[
		'@babel/transform-react-jsx',
		{
			pragma: 'createElement',
		},
	],
] )

You can see similar pattern here:

wp-calypso/webpack.config.js

Lines 312 to 313 in ecf929d

	plugins: _.compact( [
	! codeSplit && new webpack.optimize.LimitChunkCountPlugin( { maxChunks: 1 } ),

...but that's just up to code-stylistic choices. :-)

[akirk]

It would be nice if we were able to create editor.pot and editor-beta.pot respectively but I am having trouble modifying the Babel config (and thus the ouput filename for the makepot plugin) based on the "entry" in Webpack.

You can find my efforts here: https://github.com/Automattic/wp-calypso/compare/try/sdk-gutenberg-pot-generation-per-webpack-entry

It's close but I think there is a fundamental problem with both specifying a configFile as an option for babel-loader and an overrides (or plugins since we're only operating on the path subset anyway) at the same time.

Maybe some webpack+babel wizards can help us here?

[simison]

It would be nice if we were able to create editor.pot and editor-beta.pot respectively

Why would it be nice? :-)

Maybe some webpack+babel wizards can help us here?

Sure, I can have a look tomorrow (utc+3)

[jeherve]

It would be nice if we were able to create editor.pot and editor-beta.pot respectively

I think we should aim to ship all translations to WordPress.or as soon as possible, even if the feature isn't live for everyone yet; that gives translators some time to translate everything so that when the feature actually goes live, it is already translated. As such, I am okay with having only one .pot file that contains all the strings.

[simison]

Let's drop the requirement for separate pot files for now and concentrate shipping this with one file? We can always revisit in follow up PRs if it seems like we need those files separately.

[akirk]

Yes, I'm fine with doing just one POT file, my angle was just not to have the SDK having to make the decision which translations to include in what file.

[ockham]

Plot twist:

Related: WordPress/gutenberg#12559

Gutenberg will soon not use babel-plugin-makepot internally.

[stale]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.

[zinigor]

Let's close this, since Gutenberg blocks get i18n from WordPress.org repository.