GithubHelp home page GithubHelp logo

wp-cli / i18n-command Goto Github PK

View Code? Open in Web Editor NEW
93.0 93.0 50.0 1.01 MB

Provides internationalization tools for WordPress projects.

License: MIT License

PHP 41.40% Gherkin 58.60%
cli hacktoberfest i18n localization pot translation wordpress wp-cli wp-cli-package

i18n-command's Introduction

WP-CLI

WP-CLI is the command-line interface for WordPress. You can update plugins, configure multisite installations and much more, without using a web browser.

Ongoing maintenance is made possible by:

The current stable release is version 2.10.0. For announcements, follow @wpcli on Twitter or sign up for email updates. Check out the roadmap for an overview of what's planned for upcoming releases.

Testing Average time to resolve an issue Percentage of issues still open

Quick links: Using | Installing | Support | Extending | Contributing | Credits

Using

WP-CLI provides a command-line interface for many actions you might perform in the WordPress admin. For instance, wp plugin install --activate (doc) lets you install and activate a WordPress plugin:

$ wp plugin install user-switching --activate
Installing User Switching (1.0.9)
Downloading installation package from https://downloads.wordpress.org/plugin/user-switching.1.0.9.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'user-switching'...
Plugin 'user-switching' activated.
Success: Installed 1 of 1 plugins.

WP-CLI also includes commands for many things you can't do in the WordPress admin. For example, wp transient delete --all (doc) lets you delete one or all transients:

$ wp transient delete --all
Success: 34 transients deleted from the database.

For a more complete introduction to using WP-CLI, read the Quick Start guide. Or, catch up with shell friends to learn about helpful command line utilities.

Already feel comfortable with the basics? Jump into the complete list of commands for detailed information on managing themes and plugins, importing and exporting data, performing database search-replace operations and more.

Installing

Downloading the Phar file is our recommended installation method for most users. Should you need, see also our documentation on alternative installation methods (Composer, Homebrew, Docker).

Before installing WP-CLI, please make sure your environment meets the minimum requirements:

  • UNIX-like environment (OS X, Linux, FreeBSD, Cygwin); limited support in Windows environment
  • PHP 5.6 or later
  • WordPress 3.7 or later. Versions older than the latest WordPress release may have degraded functionality

Once you've verified requirements, download the wp-cli.phar file using wget or curl:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Next, check the Phar file to verify that it's working:

php wp-cli.phar --info

To use WP-CLI from the command line by typing wp, make the file executable and move it to somewhere in your PATH. For example:

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

If WP-CLI was installed successfully, you should see something like this when you run wp --info:

$ wp --info
OS:     Linux 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64
Shell:  /usr/bin/zsh
PHP binary:     /usr/bin/php8.1
PHP version:    8.1.0
php.ini used:   /etc/php/8.1/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
SQL modes:
WP-CLI root dir:        /home/wp-cli/
WP-CLI vendor dir:      /home/wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir:    /home/wp-cli/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:  /home/wp-cli/wp-cli.yml
WP-CLI version: 2.10.0

Updating

You can update WP-CLI with wp cli update (doc), or by repeating the installation steps.

If WP-CLI is owned by root or another system user, you'll need to run sudo wp cli update.

Want to live life on the edge? Run wp cli update --nightly to use the latest nightly build of WP-CLI. The nightly build is more or less stable enough for you to use in your development environment, and always includes the latest and greatest WP-CLI features.

Tab completions

WP-CLI also comes with a tab completion script for Bash and ZSH. Just download wp-completion.bash and source it from ~/.bash_profile:

source /FULL/PATH/TO/wp-completion.bash

Don't forget to run source ~/.bash_profile afterwards.

If using zsh for your shell, you may need to load and start bashcompinit before sourcing. Put the following in your .zshrc:

autoload bashcompinit
bashcompinit
source /FULL/PATH/TO/wp-completion.bash

Support

WP-CLI's maintainers and contributors have limited availability to address general support questions. The current version of WP-CLI is the only officially supported version.

When looking for support, please first search for your question in these venues:

If you didn't find an answer in one of the venues above, you can:

  • Join the #cli channel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
  • Post a new thread in the WordPress.org support forum and tag it 'WP-CLI' so it's seen by the community.

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Before submitting a bug report, please review our best practices to help ensure your issue is addressed in a timely manner.

Please do not ask support questions on Twitter. Twitter isn't an acceptable venue for support because: 1) it's hard to hold conversations in under 280 characters, and 2) Twitter isn't a place where someone with your same question can search for an answer in a prior conversation.

Remember, libre != gratis; the open source license grants you the freedom to use and modify, but not commitments of other people's time. Please be respectful, and set your expectations accordingly.

Extending

A command is the atomic unit of WP-CLI functionality. wp plugin install (doc) is one command. wp plugin activate (doc) is another.

WP-CLI supports registering any callable class, function, or closure as a command. It reads usage details from the callback's PHPdoc. WP_CLI::add_command() (doc) is used for both internal and third-party command registration.

/**
 * Delete an option from the database.
 *
 * Returns an error if the option didn't exist.
 *
 * ## OPTIONS
 *
 * <key>
 * : Key for the option.
 *
 * ## EXAMPLES
 *
 *     $ wp option delete my_option
 *     Success: Deleted 'my_option' option.
 */
$delete_option_cmd = function( $args ) {
	list( $key ) = $args;

	if ( ! delete_option( $key ) ) {
		WP_CLI::error( "Could not delete '$key' option. Does it exist?" );
	} else {
		WP_CLI::success( "Deleted '$key' option." );
	}
};
WP_CLI::add_command( 'option delete', $delete_option_cmd );

WP-CLI comes with dozens of commands. It's easier than it looks to create a custom WP-CLI command. Read the commands cookbook to learn more. Browse the internal API docs to discover a variety of helpful functions you can use in your custom WP-CLI command.

Contributing

We appreciate you taking the initiative to contribute to WP-CLI. It’s because of you, and the community around you, that WP-CLI is such a great project.

Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Read through our contributing guidelines in the handbook for a thorough introduction to how you can get involved. Following these guidelines helps to communicate that you respect the time of other contributors on the project. In turn, they’ll do their best to reciprocate that respect when working with you, across timezones and around the world.

Leadership

WP-CLI has one project maintainer: schlessera.

On occasion, we grant write access to contributors who have demonstrated, over a period of time, that they are capable and invested in moving the project forward.

Read the governance document in the handbook for more operational details about the project.

Credits

Besides the libraries defined in composer.json, we have used code or ideas from the following projects:

i18n-command's People

Contributors

benjaminprojas avatar cliffordp avatar cpiber avatar dac514 avatar danielbachhuber avatar dd32 avatar dlind1 avatar elenachavdarovasg avatar ernilambar avatar gedex avatar gitlost avatar gregsullivan avatar janw-me avatar jkrrv avatar jrfnl avatar meszarosrob avatar michaelzangl avatar oandregal avatar ocean90 avatar pbiron avatar pmbaldha avatar ponsfrilus avatar schlessera avatar shendy-a8c avatar siliconforks avatar strarsis avatar swissspidy avatar tug avatar wojsmol avatar yousan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

i18n-command's Issues

Decide on command name

@miya0001 :

makepot is verb, but other commands on wp-cli are noun. Is it ok?

We should discuss the best name for this command, as wp makepot is less than ideal.

Options so far:
wp i18n ...
wp translations ...
wp pot make

@swissspidy :

I'd prefer wp i18n, e.g. wp i18n makepot or wp i18n addtextdomain

Auto-detect plugin or theme

Right now, one needs to use either wp makepot plugin or wp makepot theme to generate a POT file for either.

There are a few differences:

  • Themes have a style.css, plugins a main plugin file, both have slightly different headers.
  • Themes have different meta data.
  • Themes have Template Name headers that might need to be extracted.

Because of the style.css / plugin file distinction, we could easily detect whether the source directory contains a theme or a plugin. Thus, we wouldn't need two commands or any other way to distinguish between these two. There would be just wp makepot, nothing else.

The only question is: are there cases where this is not wanted?

Add parameters for Language-Team header

When running wp i18n make-pot, the Language-Team header is set to LANGUAGE <[email protected]>. Adding optional parameters for --language_team and --language_team_address (URL or email) would allow users to supply their information to provide real information for this .pot header.

Command to find all text domains in a project

One suggestion in my post JavaScript Internationalization: The Missing Pieces to create separate translation files per text domain found in JavaScript files.

One way to make this possible would be a new command to find all existing text domains in a project, e.g. wp i18n find-text-domains <source> or something.

Using that list you could then run wp i18n make-pot <source> $DOMAIN.pot --domain=$DOMAIN for each domain.


Alternatively, wp i18n make-pot could have a new option à la --one-file-per-domain. However, that would mean the extractor and scanner classes would need to undergo a heavy rewrite.

Plus, a command to find all text domains might be useful on its own.

#25 is related in that regard.

Add X-Generator header to resulting POT file

A header like X-Generator: WP-CLI 2.0.0 (using WP_CLI_VERSION) could be useful for developers to see where the POT file is coming from. See #50 (comment).

Even better would be if we could also get the package's version, but I'm not sure how feasible that is.

Add option to skip PHP or JS extraction altogether

If someone uses a babel plugin or similar for JS text extraction, there's no need to do that again in the WP-CLI command.

  1. Use tool X for JS extraction
  2. wp i18n make-pot with the option to skip JS extraction and with the option to merge with existing strings.

Related: #26, #27, #29.

Translator comments are not extracted if they are not directly followed by a gettext function

Example plugin file:

<?php
/**
 * Plugin Name: Plugin name
 */

/* translators: TRANSLATORS!! */
_e( 'hello world', 'test-plugin' );

/* translators: TRANSLATORS!! */
$foo = __( 'foo', 'test-plugin' );

Running the makpot command creates this POT file:

# Copyright (C) 2017 Plugin name
# This file is distributed under the same license as the Plugin name package.
msgid ""
msgstr ""
"Project-Id-Version: Plugin name\n"
"Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/test-plugin\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <[email protected]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"POT-Creation-Date: 2017-12-13T17:11:07+00:00\n"
"PO-Revision-Date: 2017-12-13T17:11:07+00:00\n"
"X-Domain: test-plugin\n"

#. translators: TRANSLATORS!!
#: test-plugin.php:7
msgid "hello world"
msgstr ""

#: test-plugin.php:10
msgid "foo"
msgstr ""

#. Plugin Name of the plugin/theme
msgid "Plugin name"
msgstr ""

Note the missing comment for "foo".

Rethink domain handling

Right now, the script only parses gettext calls where the text domain matches the plugin slug by setting $this->translations->setDomain( $this->slug ).

This matches WordPress.org behaviour, see https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/.

However, sometimes developers include third-party libraries in their plugins with different text domains and still expect those to be extracted.

Since I'd like to keep the current behaviour as the default, maybe we can add an --ignore-domain option to the script?

The code could look like this (simplified):

if ( ! Utils\get_flag_value( $assoc_args, 'ignore-domain' ) {
    $this->translations->setDomain( $this->slug );
}

Add parameters for Last-Translator header

When running wp i18n make-pot, the Last-Translator header is set to FULL NAME <EMAIL@ADDRESS>. Adding optional parameters for --last_translator and --last_translator_address (email) would allow users to supply their information to provide real information for this .pot header.

Invoking wp i18n make-pot fails when Xdebug is enabled

In VVV after having done xdebug_on and run:

wp i18n make-pot . languages/amp-js.pot --include="*.js"

I get an error:

PHP Fatal error:  Maximum function nesting level of '100' reached, aborting! in phar:///usr/local/bin/wp/vendor/mck89/peast/lib/Peast/Syntax/Scanner.php on line 972

If I do xdebug_off then it succeeds.

The plugin context here is AMP.

Detect the textdomain by plugin header and not folder

I am using locally a folder that is not the right slug of the plugin and seems that use that (that is the same of the plugin file).
In my case the slug is defined in the root file in the headers but is not used by this command.

Uncaught Error: Class 'Peast\Peast' not found

I'm trying wp i18n make-pot . on the AMP plugin and I'm getting an error:

Plugin file detected.
PHP Fatal error:  Uncaught Error: Class 'Peast\Peast' not found in phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/JsFunctionsScanner.php:40
Stack trace:
#0 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/JsCodeExtractor.php(34): WP_CLI\I18n\JsFunctionsScanner->saveGettextFunctions(Object(Gettext\Translations), Array)
#1 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/IterableCodeExtractor.php(59): WP_CLI\I18n\JsCodeExtractor::fromString('/**\n * Adds an ...', Object(Gettext\Translations), Array)
#2 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/IterableCodeExtractor.php(86): WP_CLI\I18n\JsCodeExtractor::fromFile(Array, Object(Gettext\Translations), Array)
#3 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php(540): WP_CLI\I18n\JsCodeExtractor::fromDirectory('/srv/www/wordpr...', Object(Gettext\Translations), Array)
#4 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php(217): WP_CLI\I18n\MakePotCommand->extract_strings()
#5 [internal function]: WP_C in phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/JsFunctionsScanner.php on line 40

I'm using WP-CLI v2.0.0 installed via Phar.

Add flag to disable strings audit

For automated environments which use the make-pot command I'd like to see a flag that allows to skip audit_strings(). The output isn't viewed by someone and thus it's just unnecessary work which can be avoided.

Move command over to new v2 structure

The following changes need to be made to move the command over to the v2 structure:

  • Make sure the correct framework is required:
    composer require wp-cli/wp-cli:^2
    
  • Require the testing framework as a dev dependency:
    composer require --dev wp-cli/wp-cli-tests:^0
    
  • Use the .travis.yml file from wp-cli/wp-cli:
    wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
    
  • Add the default script configuration to Composer file:
      "scripts": {
          "lint": "run-linter-tests",
          "phpcs": "run-phpcs-tests",
          "phpunit": "run-php-unit-tests",
          "behat": "run-behat-tests",
          "prepare-tests": "install-package-tests",
          "test": [
              "@lint",
              "@phpcs",
              "@phpunit",
              "@behat"
          ]
      },
    
  • Remove scaffolded binary files:
    git rm bin/install-package-tests.sh
    git rm bin/test.sh
    
  • Remove scaffolded Behat setup:
    git rm features/bootstrap/*
    git rm features/extra/*
    git rm features/steps/*
    
  • Remove scaffolded Behat tags util script:
    git rm utils/behat-tags.php
    
  • Add command packages that are needed for Behat tests as --dev dependencies.
    The following commands are already available, anything else needs to be explicitly required:
    • cli *
    • config *
    • core *
    • eval
    • eval-file
    • help
  • Update all dependencies:
    composer update
    
  • Optional - Add PHPCS rule set to enable CS & compatibility sniffing:
    wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
    
  • Run and adapt tests to make sure they all pass:
    composer test
    

Gettext library requires PHP 5.4+

As @gitlost had noted in #13 (comment) , the Gettext library that the makepot command uses requires PHP 5.4+, which makes it unfit to be bundled with the current WP-CLI, with its PHP 5.3.29+ requirement.

Our current options:

  • Fork the oscarotero/Gettext library, make it PHP 5.3-compatible and submit PR to upstream (which is unlikely to be accepted)
  • Fork the oscarotero/Gettext library into our own org and maintain our own PHP 5.3-compatible branch
  • Keep the makepot as a separate command for now and rediscuss bundling it with WP-CLI 2.0

@gitlost, @swissspidy thoughts?

Add line number references to extracted file header data

This is something I noticed while working on #61 / #64.

When printing warnings for missing / invalid strings I want to print the warning together with the location of where that string is.

For file headers that's currently not possible because they're being extracted using regex. This is mainly because I borrowed that code from https://develop.svn.wordpress.org/trunk/tools/i18n/makepot.php, which has been doing that for years.

However, since we already leverage a powerful gettext extraction library, I wonder if we could add a new extractor just for these file headers.

retrieve_main_file_data(), get_file_data() get_file_headers(), get_file_data_from_string(), and _cleanup_header_comment() would be affected/obsoleted by such a change.

I'm not sure how feasible it is, but it would make for a more robust solution that is more similar to the other extractors and easier to test than some old regex from WordPress core.

Also, we could make sure to get the filename / line references that way.

I guess it's the same argument as regex vs. using a DOM parser to parse some HTML in PHP.


I just saw that the Template Name: extraction already resides in \WP_CLI\I18n\IterableCodeExtractor.

We should probably consolidate this somehow.

Add option to merge newly extracted strings with existing ones

If there's already a POT file (either at the specified destination or one passed via an argument), e.g. one created by https://github.com/WordPress/packages/tree/master/packages/babel-plugin-makepot (see #26), it could be useful to merge these with the ones extracted by make-pot.

Example use case:

  1. Extract JS strings using Babel, store them in my-plugin.pot.
  2. Extract PHP strings using wp i18n make-pot, merge with the ones from my-plugin.pot, store both in my-plugin.pot again.

There could be a new option, --merge, which can be either used without value (= merge with destination file if it exists) or with a specified POT file (--merge=my-plugin-js-strings.pot).

This would help with point 2 mentioned in https://make.wordpress.org/core/2018/05/01/javascript-internationalization-the-missing-pieces/:

Use that POT file to write the exact same internationalization functions in a “fake” PHP file that can be scanned by the WordPress.org translation platform. This will result in PO and MO files containing all of your plugin’s translations.

Allow passing custom headers and comments for POT file

Currently, wp i18n make-pot generates a .pot file and adds a link to the WordPress plugin or theme repo page as the Report-Msgid-Bugs-To header.

See:

For plugins and themes which are not distributed via WordPress repos, adding an optional parameter such as --bugs_address could be used to supply an alternate link (e.g. to a GitHub issues page).

PHP Parse error: syntax error, unexpected '[' in .../MakePotCommand.php on line 29

Summary
We have multiple web hosting accounts with the same web host, one of which has an installation of WP-CLI that is misbehaving.

Recently, I installed WP-CLI in a new hosting environment, but it failed to start, due to the following error...

PHP Parse error: syntax error, unexpected '[' in phar:///[redacted]/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php on line 29

Steps to reproduce
The same error is generated regardless of what command is used...essentially, WP-CLI fails to start.

What's interesting is the fact that we have several other sites hosted at the same web host using the same hosting plan (same server specs, software, etc.). Each hosting account is running PHP 7.0.30 with the default extensions loaded, and running WP-CLI version 2.0.0. Each account is hosting a WordPress website with a custom built theme, but all relatively similar in development to the others.

I just can't for the life of me figure out why we have multiple instances of WP-CLI, each hosted in practically identical environments, but only the one is throwing a syntax error.

Environment

CentOS release 6.10 (Final)
Apache/2.2.34 (Unix) / PHP 7.0.30

Loaded extensions - apc, bz2, calendar, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconvi magick, imap, intl, json, libxml, mbstring, mcrypt, memcache, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, readline, redis, Reflection, session

The only real difference between the hosting environments that I can find is on the affected server, which is running Phar 2.0.1, whereas on the other accounts where WP-CLI is functioning properky, are running Phar 2.0.2, and all are running the same API version (1.1.1).

TIA

Error: Callable "\\WP_CLI\\I18n\\Command_Namespace" does not exist

Hi! After installing the package with wp package install [email protected]:wp-cli/i18n-command.git and received a Success: Package installed. message, running wp i18n produced Error: Callable "\\WP_CLI\\I18n\\Command_Namespace" does not exist, and cannot be registered as ``wp i18n``.

Commenting the 14th line of i18n-command.php ( WP_CLI::add_command( 'i18n', '\WP_CLI\I18n\Command_Namespace' );) seemed to solve the problem for me, but I really don't know if it's the best way to make it.

Thanks a lot!

Add description comment to POT file

As noted in #47 (comment):

I just noticed that the original makepot.php script has a description field for projects, e.g. Translation of the WordPress theme {name} {version} by {author}. However, that appears to be unused.

We might want to add this as a default comment to the POT file though as it can be useful when opening a POT file without context.

Inconsistent debug messages

When running wp i18n make-pot with the --debug flag, one currently sees messages like this:

Debug (make-pot): Plugin file: /foo-plugin/foo-plugin.php (0.089s)
Debug (make-pot): Destination: /foo-plugin//languages/glossary-by-codeat.pot (0.09s)

Besides fixing the wrong // in the output there, I think we could improve this output a bit more. For example, we could print the final text domain that will be used for scanning, and some other helpful details like the total number of found strings.

`wp makepot theme|plugin . foo.pot` doesn't work

$ wp makepot plugin . languages/foo.pot
PHP Warning:  chdir(): No such file or directory (errno 2) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110

Warning: chdir(): No such file or directory (errno 2) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110
PHP Warning:  chdir(): No such file or directory (errno 2) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110

Warning: chdir(): No such file or directory (errno 2) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110
PHP Warning:  chdir(): No such file or directory (errno 2) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110

...

Warning: chdir(): File name too long (errno 63) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 110
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 130

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /wp-cli-makepot/src/WordPressCodeExtractor.php on line 130

Ignore minified JavaScript files

Right now, we exclude some files by default. One file pattern that we don't yet exclude is minified JavaScript files. They usually look like i-am-minified.min.js.

It's not currently possible to exclude files using glob patterns like *.min.js but I think that would be a great addition.

When someone excludes *.min.js, we can turn this into a regex à la .*\.min.js or something, and then exclude the file if it matches that regex. WP_oEmbed::get_provider() has some code that does this. Perhaps we can reuse this.

In the PHP extractor, the relevant code is here:

/** @var DirectoryIterator $file */
if ( in_array( $file->getBasename(), $exclude, true ) ) {
return false;
}
// Check for more complex paths, e.g. /some/sub/folder.
foreach( $exclude as $path_or_file ) {
if ( false !== mb_ereg( preg_quote( '/' . $path_or_file ) . '$', $file->getPathname() ) ) {
return false;
}
}
/** @var RecursiveCallbackFilterIterator $iterator */
if ( $iterator->hasChildren() ) {
return true;
}
return ( $file->isFile() && 'php' === $file->getExtension() );

We can probably extend this with a new regex.

Require database when you run i18n

I was trying the package on my host where I have VVV as VM, so is not easy to share the same database.
When I execute wp i18n alert me that the mysql connection didn't worked.

If I execute make-pot instead this error doesn't appear and I can use it without problems.
I am not sure if this behaviour on first level command require a db connection and the others can ignore that but just to let know about this error.

Don't include empty file headers

Noticed while testing #4.

Example plugin file:

<?php
/**
 * Plugin Name: Plugin name
 */

Running the makpot command creates this POT file:

# Copyright (C) 2017 Plugin name
# This file is distributed under the same license as the Plugin name package.
msgid ""
msgstr ""
"Project-Id-Version: Plugin name\n"
"Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/test-plugin\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <[email protected]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"POT-Creation-Date: 2017-12-13T17:14:45+00:00\n"
"PO-Revision-Date: 2017-12-13T17:14:45+00:00\n"
"X-Domain: test-plugin\n"

#. Plugin Name of the plugin/theme
msgid "Plugin name"
msgstr ""

#. Plugin URI of the plugin/theme
#. Description of the plugin/theme
#. Author of the plugin/theme
#. Author URI of the plugin/theme
msgid ""
msgstr ""

Note the empty msgid entry.

Automatically rerun failed scenarios

The following changes need to be made:

  1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:
- composer behat || composer behat-rerun
  1. In the composer-json file, the requirement on wp-cli/wp-cli-tests needs to be adapted to require at least v2.0.7:
"wp-cli/wp-cli-tests": "^2.0.7"
  1. In the composer-json file, the "scripts" section needs to be extended. Immediately after the line "behat": "run-behat-tests",, the following line needs to be inserted:
"behat-rerun": "rerun-behat-tests",

Here's an example of how this should look like:

Class 'Gettext\Translations' not found in phar

I'm trying this command and got the following fatal error:

Fatal error: Uncaught Error: Class 'Gettext\Translations' not found in phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php:340
Stack trace:
#0 phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php(215): WP_CLI\I18n\MakePotCommand->handle_arguments(Array, Array)
#1 [internal function]: WP_CLI\I18n\MakePotCommand->__invoke(Array, Array)
#2 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(89): call_user_func(Array, Array, Array)
#3 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#4 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(425): call_user_func(Object(Closure), Array, Array)
#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(365): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(388): WP_CLI\Runner->run_command(Array, Array)
#7 phar:///usr/local/bin/wp/vendor in phar:///usr/local/bin/wp/vendor/wp-cli/i18n-command/src/MakePotCommand.php on line 340

WP-CLI 2.0.0 (phar).
OS: OS X 10.13

Explore usefulness for WordPress core

Right now the command requires a plugin or theme header to work. These allow setting the slug, text domain, etc. easily.

But what if we could use this for WordPress core / WordPress.org as well?

The current makepot.php script handles various special cases:

  • Different meta data for the various projects
  • Multiple POT files for WordPress admin, frontend, and timezones
    Here's where the new --exclude option comes in handy
  • There's no text domain, so this would be a good use case for an --ignore-domain argument (#35)
  • No plugin or theme header that can be parsed

Add option to skip PHP string extraction

In addition to skipping JS string extraction and skipping string audits (#94) I was thinking about a --skip-php option.

This could be useful when one only wants to extract strings from JS files (for whatever reason).

Obviously plugin/theme meta data would still need to be scanned to find the destination folder etc.

Audit functionality

Just thinking out loud after reading through https://core.trac.wordpress.org/ticket/44139.

We might be able to generate some warnings when a string occurs multiple times in the source code but with multiple translator comments. That‘s usually an indication that these should be separate strings with different contexts.

Not possible to include `vendor`

Add different output formats

As mentioned in #33, it could be useful if the warnings and messages generated by the make-pot command are available in another format, for example JSON.

This way users can programmatically run the command, easily extract the output and process it further.

My own use case would be to run wp i18n make-pot every time I push code to GitHub and import translations into GlotPress. I want to be able to send a notification if there are any wrong translator comments or anything else.

Create directories for output if they don't exist yet

Running wp makepot theme path/to/theme path/to/theme/languages/foo.pot when languages doesn't exist yet produces the following output:

PHP Warning:  file_put_contents(languages/foo.pot): failed to open stream: No such file or directory in /.wp-cli/packages/vendor/gettext/gettext/src/Generators/Generator.php on line 16

Warning: file_put_contents(languages/foo.pot): failed to open stream: No such file or directory in /.wp-cli/packages/vendor/gettext/gettext/src/Generators/Generator.php on line 16
Error: Could not generate a POT file!

Error: 'i18n' is not a registered wp command.

After installing wp-cli using latest (1.5.0) .deb build from builds repo, I'm stuck with this error :
Error: 'i18n' is not a registered wp command. See 'wp help' for available commands.

I tried an older package (1.3.0) but the problem is also present.

sebastien@computer:~$ wp --info
OS:	Linux 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php7.0
PHP version:	7.0.22-0ubuntu0.16.04.1
php.ini used:	/etc/php/7.0/cli/php.ini
WP-CLI root dir:	phar://wp-cli.phar
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/home/sebastien
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	1.5.0
sebastien@computer:~$ wp i18n
Warning: No WordPress install found. If the command 'i18n' is in a plugin or theme, pass --path=`path/to/wordpress`.
Error: 'i18n' is not a registered wp command. See 'wp help' for available commands.

sebastien@computer:~/www/wordpress$ wp i18n
Error: 'i18n' is not a registered wp command. See 'wp help' for available commands.
sebastien@computer:~$ uname -a
Linux computer 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

sebastien@computer:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

Note: the command wp package install [email protected]:wp-cli/i18n-command.git won't works too (it generates other error message) and Travis seems to be angry with latest commits.

So I suppose a problem from here...

Error after clean install

Hi, I just installed this package using the following command :

sebastien@computer:~$ wp package install [email protected]:wp-cli/i18n-command.git
Installing package wp-cli/i18n-command (dev-master)
Updating /home/sebastien/.wp-cli/packages/composer.json to require the package...
Registering [email protected]:wp-cli/i18n-command.git as a VCS repository...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.630 seconds
Analyzed 5408 packages to resolve dependencies
Analyzed 311465 rules to resolve dependencies
Package operations: 3 installs, 0 updates, 0 removals
Installs: gettext/languages:2.3.0, gettext/gettext:v4.4.3, wp-cli/i18n-command:dev-master 93c1109

  • Installing gettext/languages (2.3.0)
  • Warning: gettext/gettext v4.4.3 requires gettext/languages ^2.3 -> satisfiable by gettext/languages[2.3.0].
  • Installing gettext/gettext (v4.4.3)
  • Warning: wp-cli/i18n-command dev-master requires gettext/gettext ^4.4 -> satisfiable by gettext/gettext[v4.4.0, v4.4.1, v4.4.2, v4.4.3].
  • Installing wp-cli/i18n-command (dev-master 93c1109)
    Writing lock file
    Generating autoload files
    ---
    Success: Package installed.

But when I want to use it, I got this error message :

sebastien@computer:~$ wp i18n
Error: Callable "\WP_CLI\I18n\Command_Namespace" does not exist, and cannot be registered as wp i18n.


Here the tree of my .wp-cli folder :

sebastien@computer:~$ find .wp-cli -type d
.wp-cli
.wp-cli/packages
.wp-cli/packages/vendor
.wp-cli/packages/vendor/bin
.wp-cli/packages/vendor/wp-cli
.wp-cli/packages/vendor/wp-cli/i18n-command
.wp-cli/packages/vendor/wp-cli/i18n-command/.git
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/info
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs/refs
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs/refs/heads
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs/refs/remotes
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs/refs/remotes/origin
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/logs/refs/remotes/composer
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/branches
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs/tags
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs/heads
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs/remotes
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs/remotes/origin
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/refs/remotes/composer
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/objects
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/objects/pack
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/objects/info
.wp-cli/packages/vendor/wp-cli/i18n-command/.git/hooks
.wp-cli/packages/vendor/wp-cli/i18n-command/features
.wp-cli/packages/vendor/wp-cli/i18n-command/features/steps
.wp-cli/packages/vendor/wp-cli/i18n-command/features/extra
.wp-cli/packages/vendor/wp-cli/i18n-command/features/bootstrap
.wp-cli/packages/vendor/wp-cli/i18n-command/src
.wp-cli/packages/vendor/wp-cli/i18n-command/bin
.wp-cli/packages/vendor/wp-cli/i18n-command/utils
.wp-cli/packages/vendor/wp-cli/i18n-command/.github
.wp-cli/packages/vendor/gettext
.wp-cli/packages/vendor/gettext/gettext
.wp-cli/packages/vendor/gettext/gettext/.git
.wp-cli/packages/vendor/gettext/gettext/.git/info
.wp-cli/packages/vendor/gettext/gettext/.git/logs
.wp-cli/packages/vendor/gettext/gettext/.git/logs/refs
.wp-cli/packages/vendor/gettext/gettext/.git/logs/refs/heads
.wp-cli/packages/vendor/gettext/gettext/.git/logs/refs/remotes
.wp-cli/packages/vendor/gettext/gettext/.git/logs/refs/remotes/origin
.wp-cli/packages/vendor/gettext/gettext/.git/logs/refs/remotes/composer
.wp-cli/packages/vendor/gettext/gettext/.git/branches
.wp-cli/packages/vendor/gettext/gettext/.git/refs
.wp-cli/packages/vendor/gettext/gettext/.git/refs/tags
.wp-cli/packages/vendor/gettext/gettext/.git/refs/heads
.wp-cli/packages/vendor/gettext/gettext/.git/refs/remotes
.wp-cli/packages/vendor/gettext/gettext/.git/refs/remotes/origin
.wp-cli/packages/vendor/gettext/gettext/.git/refs/remotes/composer
.wp-cli/packages/vendor/gettext/gettext/.git/objects
.wp-cli/packages/vendor/gettext/gettext/.git/objects/pack
.wp-cli/packages/vendor/gettext/gettext/.git/objects/info
.wp-cli/packages/vendor/gettext/gettext/.git/hooks
.wp-cli/packages/vendor/gettext/gettext/src
.wp-cli/packages/vendor/gettext/gettext/src/Utils
.wp-cli/packages/vendor/gettext/gettext/src/Generators
.wp-cli/packages/vendor/gettext/gettext/src/Extractors
.wp-cli/packages/vendor/gettext/gettext/tests
.wp-cli/packages/vendor/gettext/gettext/tests/assets
.wp-cli/packages/vendor/gettext/gettext/tests/assets/phpcode
.wp-cli/packages/vendor/gettext/gettext/tests/assets/twig
.wp-cli/packages/vendor/gettext/gettext/tests/assets/jscode
.wp-cli/packages/vendor/gettext/gettext/tests/assets/po2
.wp-cli/packages/vendor/gettext/gettext/tests/assets/po
.wp-cli/packages/vendor/gettext/gettext/tests/assets/phpcode2
.wp-cli/packages/vendor/gettext/gettext/tests/assets/blade
.wp-cli/packages/vendor/gettext/gettext/tests/assets/po3
.wp-cli/packages/vendor/gettext/gettext/tests/assets/jscode2
.wp-cli/packages/vendor/gettext/gettext/tests/assets/phpcode3
.wp-cli/packages/vendor/gettext/gettext/tests/assets/jed
.wp-cli/packages/vendor/gettext/languages
.wp-cli/packages/vendor/gettext/languages/.git
.wp-cli/packages/vendor/gettext/languages/.git/info
.wp-cli/packages/vendor/gettext/languages/.git/logs
.wp-cli/packages/vendor/gettext/languages/.git/logs/refs
.wp-cli/packages/vendor/gettext/languages/.git/logs/refs/heads
.wp-cli/packages/vendor/gettext/languages/.git/logs/refs/remotes
.wp-cli/packages/vendor/gettext/languages/.git/logs/refs/remotes/origin
.wp-cli/packages/vendor/gettext/languages/.git/logs/refs/remotes/composer
.wp-cli/packages/vendor/gettext/languages/.git/branches
.wp-cli/packages/vendor/gettext/languages/.git/refs
.wp-cli/packages/vendor/gettext/languages/.git/refs/tags
.wp-cli/packages/vendor/gettext/languages/.git/refs/heads
.wp-cli/packages/vendor/gettext/languages/.git/refs/remotes
.wp-cli/packages/vendor/gettext/languages/.git/refs/remotes/origin
.wp-cli/packages/vendor/gettext/languages/.git/refs/remotes/composer
.wp-cli/packages/vendor/gettext/languages/.git/objects
.wp-cli/packages/vendor/gettext/languages/.git/objects/pack
.wp-cli/packages/vendor/gettext/languages/.git/objects/info
.wp-cli/packages/vendor/gettext/languages/.git/hooks
.wp-cli/packages/vendor/gettext/languages/src
.wp-cli/packages/vendor/gettext/languages/src/cldr-data
.wp-cli/packages/vendor/gettext/languages/src/cldr-data/main
.wp-cli/packages/vendor/gettext/languages/src/cldr-data/main/en-US
.wp-cli/packages/vendor/gettext/languages/src/cldr-data/supplemental
.wp-cli/packages/vendor/gettext/languages/src/Exporter
.wp-cli/packages/vendor/gettext/languages/bin
.wp-cli/packages/vendor/gettext/languages/tests
.wp-cli/packages/vendor/gettext/languages/tests/Get
.wp-cli/packages/vendor/gettext/languages/tests/Rules
.wp-cli/packages/vendor/composer

conserve X-Poedit-* headers with --merge

When using: wp i18n make-pot . languages/theme.pot --merge on a pot file already created with POedit, I'd like to keep custom headers since they contain many useful hints for contributors (possibly using poedit).
Eg:

"X-Poedit-Basepath: ..\n"
"X-Poedit-KeywordsList: __;_e;_n;_x;_ex;_nx;esc_attr__;esc_attr_e;esc_attr_x;esc_html__;esc_html_e;esc_html_x;_n_noop;_nx_noop;translate_nooped_plural\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Poedit-SearchPath-0: .\n"
"X-Poedit-SearchPathExcluded-0: foo\n"
"X-Poedit-SearchPathExcluded-1: bar.php\n"

Add option to exclude certain folders and files

The make-pot command currently scans all files with a .php extension (or .js, see #26).

In many cases, there might be files and folders that shouldn't be scanned. Some examples:

  • node_modules/ (npm modules)
  • Gruntfile.js
  • webpack.config.js
  • vendor/ (Composer dependencies)
  • .git, .svn, .svn -> basically anything with a dot prefix

Being able to exclude these files would increase performance and create less POT files with potentially unwanted strings in it.

Perhaps there could be even a default list of folders and files to include.

Display warnings for invalid text domains

I will explain better, taking this and doing that:

wget https://downloads.wordpress.org/plugin/glossary-by-codeat.1.6.2.zip
unzip glossary-by-codeat.1.6.2.zip
cd glossary-by-codeat/
wp i18n make-pot . ./test.pot

I am getting a file with this content:

# Copyright (C) 2018 Glossary
# This file is distributed under the same license as the Glossary package.
msgid ""
msgstr ""
"Project-Id-Version: Glossary 1.6.2\n"
"Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/glossary-by-codeat\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <[email protected]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"POT-Creation-Date: 2018-07-10T17:17:54+02:00\n"
"PO-Revision-Date: 2018-07-10T17:17:54+02:00\n"
"X-Domain: glossary-by-codeat\n"

#. Plugin Name of the plugin
msgid "Glossary"
msgstr ""

#. Plugin URI of the plugin
msgid "http://codeat.co/glossary"
msgstr ""

#. Description of the plugin
msgid "Easily add and manage a glossary with auto-link, tooltips and more. Improve your internal link building for a better SEO."
msgstr ""

#. Author of the plugin
msgid "Codeat"
msgstr ""

#. Author URI of the plugin
msgid "http://codeat.co"
msgstr ""

But seems that is not scanning also if the output is:

Plugin file detected.
Success: POT file successfully generated!

I was thinking that the issue was generated by #41 but I updated right now the package and tried with the package from the wp.org just to work on the best case.
I say not scanning because is very fast and there isn't a verbose parameter to see what file is scanning to see if is working well.

Add flag to disable file meta data extraction

Use case:

I want to extract all JS strings from a plugin and then write these to a temporary PHP file using the pot-to-php script included in the @wordpress/i18n package.

For this, it's unnecessary to also extract the plugin/theme meta data (plugin name, description, etc.) as this is already done by WordPress.org

Add warnings for more scenarios

Previously: #33.


The WordPress Coding Standards project has a few sniffs that we could borrow from to improve the warnings created by the make-pot command.

These sniffs currently do:

  • Check for the presence of a translators comment if one of the text strings contains a placeholder.
  • Check for inconsistencies between single and plural arguments.
  • Check for multiple unordered placeholders.
  • Check that the translatable string itself is not empty

Source: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/blob/eccb1f721f95fdcf5c2e383340aa4b094c0317ad/WordPress/Sniffs/WP/I18nSniff.php#L36-L59

Let's determine whether it makes sense to port some of these over to WP-CLI.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.