Just so there aren't any conflicts when there are multiple Traduttore installs on a server.

Code in question:

Related: #67

We should some general docs for troubleshooting / FAQs for people to help debug common issues.

Examples:

• why no translations have been updated
• why no zip file has been built
• debug string extraction issues
• test WP-CLI availability
• test git configuration and repository access
• test configuration of a project (i.e. is the repository url correct and the repository reachable)

I think we should reduce the time when teh ZIP file is created.

As it is a one time event it should be Ok to run near instantaneous.

My recommendation would be to reduce it to 5 minutes from 15 minutes.

In #3 the time we wait until the next ZIP file generation has been reduced to 5 minutes.

I get it that one doesn't want to wait 15 minutes all the time, but when lots of translations are happening, it gets noisy quickly:

Can we somehow prevent this by throttling notifications or changing the time again? For the latter I suggest making them filterable. Both for the incoming webhook event as well as the language pack generation.

Although the plugin now theoretically supports fetching projects from Bitbucket and GitLab.com, we don't support receiving webhooks from these providers just yet.

Without that support, the plugin isn't that useful when on these platforms.

Right now we add a custom github-webhook/v1/push-event REST route for consuming incoming GitHub webhooks. This has two big disadvantages:

• The name is not really uniquely namespaced.
• The REST callback is very GitHub-specific, e.g. by checking for X-GitHub-Event headers and assuming a certain data structure.

Possible solutions:

• Add a new traduttore/v1/<provider>-incoming REST route for each provider. Examples:
  • traduttore/v1/github-incoming
  • traduttore/v1/bitbucket-incoming
  • traduttore/v1/gitlab-incoming
  • traduttore/v1/custom-incoming (common route for custom repositories with filterable callback)
• Deprecate github-webhook/v1/push-event in favor of traduttore/v1/github-incoming
  Migration might be easier with something like #55
• Alternatively: use only one REST route, e.g. traduttore/v1/incoming-webhook and choose correct handler depending on source. This could be a separate class per source.
  The question here would be how the source could be detected in a reliable matter.

Bitbucket documentation:

https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html
https://confluence.atlassian.com/bitbucket/event-payloads-740262817.html

GitLab documentation:

https://docs.gitlab.com/ee/user/project/integrations/webhooks.html

Let's follow progress at https://core.trac.wordpress.org/ticket/45103 and https://meta.trac.wordpress.org/ticket/3875 to see what we can do in Traduttore to support that.

Right now it looks like we have to create files like {$domain}-{$locale}-{$md5}.json where $md5 is the MD5 hash of the JS file path.

Defining these secrets in wp-config.php means you can't easily use this with Multisite or with multiple self-managed GitLab repositories unless they all share the same secret.

Retrieving the secret could be filterable and we could still fall back to the defined constants there for BC.

Related #57.

• The server running the plugin needs be able to connect to GitHub via SSH and has access to the requested repos.
• For the POT generation, WP-CLI with the i18n-command is required.
• TRADUTTORE_WP_BIN can be used to customize the path of WP-CLI bin.

There's no reason for ZipProvider::get_last_build_time() to be static.

Everywhere we're using it, we already instantiate a new ZipProvider object anyway.

When running wp i18n make-pot, the script notifies you when an extracted string has two or more different translator comments.

See https://github.com/wp-cli/i18n-command/blob/7e11d8c2ead4787997c41fb77809f7c90ef787ca/src/MakePotCommand.php#L315-L321 and https://github.com/wp-cli/i18n-command/blob/7e11d8c2ead4787997c41fb77809f7c90ef787ca/features/makepot.feature#L528-L556.

This is usually a sign of a developer mistake, as the string would only be imported once in GlotPress, but have 2 comments added to it.

Here's an (over simplified) example:

/* translators: Translators 1! */
sprintf( __( 'Hello World', 'foo-plugin' );

/* Translators: Translators 2! */
__( 'Hello World', 'foo-plugin' );

What if Traduttore would send a Slack notification when such a warning is encountered? (*)

The same goes for other warnings:

• Files that can't be opened
• Files that can't be parsed and need to be reviewed and perhaps excluded
• The command fails for another reason and exits with a non-zero status

(*) Now that I think about it, this could also work as a HM Linter integration 🤯

It would be very convenient to import translations for a newly added project without having to manually run wp traduttore update or waiting for the next commit.

Perhaps by adding a single cron event when saving a project or by adding a button to the UI.

It would be great if we could automatically create the additional POT file if https://github.com/WordPress/packages/tree/master/packages/babel-plugin-makepot is being used or at least make it so that we can merge the generated POT file with an existing one.

For the latter option, we'd need a way for plugins to tell Traduttore where to find that POT file (config file?) unless we want to scan the whole directory first for existing POT files.

https://github.com/wearerequired/traduttore/blob/379945a/inc/TranslationApiRoute.php#L57

Since the language pack build is delayed a bit the updated value isn't correct. Currently it's possible that you get an old language pack even the updated value told to you that it's newer.

Consider using filemtime() or store the actual build time in a meta field.

Extracted from #70:

We don't want to test if Git/Mercurial/Subversion are actually working, but whether the behavior of the classes is correct. Otherwise tests fail if the software isn't installed on your machine (or the CI provider).

I've looked into https://github.com/php-mock/php-mock-phpunit and https://github.com/mikehaertl/php-shellcommand for mocking exec() calls and some sort of Command dependency injection.

For the times where you know the cached repository is up-to-date so you don't want to unnecessarily run git reset and git pull, just good old wp i18n make-pot on it.

This could be done by adding a --cached flag to UpdateCommand and passing that as an argument to \Required\Traduttore\Runner::run(). In that case that method would simply call \Required\Traduttore\Loader::get_local_path() instead of \Required\Traduttore\Loader::download().

And if \Required\Traduttore\Loader::get_local_path() returns null you know a cached repository doesn't exist and can throw an error in the terminal accordingly.

It wouldn't be hard to make Traduttore support more than GitHub, e.g. also GitLab or Bitbucket.

I kinda hijacked the existing Traduttore plugin for #1 and #2.

Previously it only handled some customizations for translate.required.com. Now it does a whole lot more.

If we want to open source our solution (the blog post is ready) and easy to set up for others, it would make sense to keep the site customizations and the import / ZIP generation / API parts in two (or more?) separate projects.

Thoughts?

Let's eat our own dogfood, make Traduttore translatable and use Traduttore Registry to load translations.

For #48 we need some more powerful Slack notifications. At least attachments would be helpful. And buttons. And unicorns.

We currently support https://wordpress.org/plugins/slack/, however that plugin is a bit limited in terms of available formatting and hasn't been updated in quite some time.

https://wordpress.org/plugins/dorzki-notifications-to-slack/ looks like a promising alternative.

For the time being we could support both, with the new one being the preferred solution for some more powerful Slack notifications.

Integrations seems to be pretty straightforward, see https://github.com/wearerequired/required-jobboard/pull/12 and https://github.com/dorzki/Slack-Notifications

WP_CLI::error is used by accident in Plugin::github_webhook_push():

WP_CLI is not imported nor available in this case.

Introduced in 17f3ba4 by copy/pasting some code.

We can simply delete these lines as there's a if ( ! $project ) { check right after it.

After successfully giving a talk about WordPress I18N Workflows, telling everyone how great Traduttore is. I even promoted it as "WordPress.org for everyone". After that, I wondered: how can we make this statement really true? How can we make it easier for people to use this?

Setting up Traduttore requires quite some technical knowledge, so I doubt many people or agencies will use it out of the box. There's only so much we can do with better documentation and UI changes either.

What if we built some simple Multisite solution where everyone can create their own Traduttore instance, connecting their private plugins and using this platform to translate them?

It would truly be (translate.)WordPress.org for everyone. Kinda what platforms like Transifex & co. do, but really tailored to the WordPress community.

Run PHPCS now, and later the unit tests (#18)

The milestone is almost closed.

Only needs a final review, changelog, tag, and GitHub release.

Each time you use wp traduttore translations build a new language pack is built even if the translations haven't changed since the last build.

To do:

• Review documentation
• Update changelog
• Tag new release
• Bump branch alias in composer.json

Perhaps something for the CLI commands

b6f6ceb is worth a new tag IMO.

When nothing has changes you get the following notification:

Project Name: 0 new strings were added, 0 were fuzzied, and 0 were obsoleted. There were 0 errors

IMO we should suppress such messages in

Previously: #12.

We likely need to support more if not all options that can be passed to wp i18n make-pot.

Note: Instead of putting them all together with sprintf() and exec() it's probably easier to use something like https://github.com/mikehaertl/php-shellcommand. We can then just iterate through an args array and add them all to the command object.

Need to figure out how this can be best handled without requiring too much manual work.

Related: #57, #64

I updated the translations on translate.required.com but WP-CLI is not downloading the latest version.

wp @stage language core update
Updating 'German' translation for Swisscom Post Types ...
Using cached file '/home/deploy/.wp-cli/cache/translation/plugin-swisscom-content-types--de_DE-1522156473.zip'...
Entpacken der aktualisierten Version …
Die aktuelle Version wird installiert …
Die Übersetzung wurde erfolgreich aktualisiert.
Success: Updated 1/1 translations.

Extracted from #70:

We might need to move some stuff around. For example delete_local_repository() might make more sense in the Updater instead of Runner.

Issue Overview

In #70 we discussed how we can better protected the incoming webhook route for Bitbucket requests.

Bitbucket.org doesn't support secrets, so it's not really possible to verify these requests.

Right now we simply let all requests pass, which is not ideal.

What we could do:

• Check request headers to verify that the requests come from Bitbucket
  Error prone, doesn't help that much.
• Disallow these incoming webhooks by default and have users filter the responses to make them work.
  Poor UX because they don't work out of the box.

Additional context
#70

Useful for unit tests and when a ZIP archive gets broken somehow. We could add a CLI command that calls ZipProvider:: remove_zip_file() in this case.

• Update changelog
• Update version in plugin file header
• Create a new tag
• Create a new GitHub release

• traduttore_zip_generated
• traduttore_updated_from_github
• #38

Not sure if the readme would be the right place for this. It already has a lot of information. Maybe we should start splitting the file into a /docs directory?

See https://getcomposer.org/doc/articles/aliases.md#branch-alias

"branch-alias": {
    "dev-master": "2.0.x-dev"
}

This would allow someone to test upcoming versions of the 2.x branch.

Basically like https://github.com/wp-cli/entity-command, but for project meta, I'd want an easy way to set project meta information like VCS type and things like that using WP-CLI.

Not sure how easy it would be to require that command and extend \WP_CLI\CommandWithMeta. Otherwise we'd have to copy the code a bit.

Also, this might be something for GlotPress itself and not specifically Traduttore.

Per discussion at #38 (comment)

If BC is a concern, we can use do_action_deprecated and do_action in tandem for a while.

• Bring readme for Traduttore and Traduttore Registry up to date
• Link to the other project in each readme
• Make sure the version numbers are correct
• Tag a version 1.0.0 for both projects (or 2.0.0?)
• Maybe add a changelog (or use GitHub releases)
• Make sure the composer.json files are up to date.
• Whatever else I forgot

Currently not the case for translation set meta data.

#70 will add project meta data too.

Advantages:

• Easier to use
• No need to manually create webhooks
• Status updates / progress for GitHub pull requests
• Inline annotations in pull requests for faulty text strings marked by WP-CLI

The uninstall.php doesn't yet use WP_Filesystem to get rid of all files and folders.

Some thoughts about possible WP-CLI commands for easier debugging:

wp traduttore info

This could show some status information, e.g. things like:

• Plugin version
• Path to git binary
• Path to WP-CLI binary
• Path to cache dir
• Whether requirements (git, WP-CLI i18n-command, zip extension, Slack plugin, etc.) are met
• …?

wp traduttore debug <project>

• Repository information (type, vcs type, url, visibility)
• Path to the cached repository
• Whether the repository exists and Traduttore has access to it

Background: https://required.slack.com/archives/C4YP8FVB5/p1525731910000044

wp traduttore translations update https://github.com/user/repo/
fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
Warning: Could not update translations for project (ID: 123)!

Having a command to remove a broken Git repository in /tmp is easier than having to try finding out where that repo is and to delete it via SSH.

GitHubUpdater::remove_local_repository() calls rmdir() but doesn't remove its content first.

Warning: rmdir(/tmp/traduttore-github-foo): Directory not empty in /content/plugins/traduttore/inc/GitHubUpdater.php on line 88

This way we don't have to guess the repsitory URL based on the "Source file URL" field.

Also, one might want to use Traduttore without having "Source file URL" set.