Internationalization - Create and Standardize

[hellofromtonya]

Create an internationalization project to collect and standardize translations of Beans. Consider a tool like GlotPress or other.

[GaryJones]

If #61 is successful, then translate.wordpress.org can handle locale submissions.

If not, I can say from experience, that setting up a self-hosted version of GlotPress is not difficult, though it does mean managing contributor signups.

There are Grunt/Gulp tools though, that allow you to pull a translation set from GlotPress, which makes the release process regarding localisation much easier.

[ibes]

I support #61 and handle the languages the official way.

With the setup we want use we will need this way to handle language files: https://wp-languages.github.io/

Would be great to get Beans language files through the official way.

If that is not possible, I would this or that way, vote for a composer accessible way.

I am not really experienced with GlotPress - but as far as I get it, it helps the cooperation. That sounds like a good idea.

[hellofromtonya]

Infrastructure

In thinking more about this feature, I'm proposing the following:

1. Create a translate subdomain on our main getbeans.io site: https://translate.getbeans.io`.
2. Use GlotPress on that subdomain.

This infrastructure would give the Community the ability to add translations for Beans, child themes, and plugins.

Get Translations into Beans

For the specific Beans translations, the next step is: how to get those into the framework? We have a couple of choices:

1. Build a plugin called Beans Translations.
2. Roll it directly into the framework itself.

I like option 2 as it provides translations out-of-the-box without requiring users to install a separate plugin.

What does everyone else think?

[christophherr]

👍 on the infrastructure. Let's keep it as close to WP as possible.

Not sure if I like the idea of having 20+ translations bundled with the framework. The perfect solution for the user, in my mind, would be something like:

• The locale of the WP installation is changed or WP is used with a different locale to begin with.
• Beans is installed, checks the locale and maybe calls the Beans api.
• When a translation file exists, Beans offers to install it.
• User decides. If yes, Beans downloads and installs the translation.

I like the idea of a plugin, too.

[ibes]

Bringing in the Composer way to include Beans: I need a way to fetch files from a well known public accessible place.

@christophherr suggestion sounds nice for users who have a consistent state on the server.

But we should also have a way so pages can be set up via build processes - thinking about destroying all existing code and build it completely new at each release (media and database needs to be consistent for sure )

Regular translations can be handled that way: https://wp-languages.github.io/

If there is a "Beans Translations" - would that plugin include all translation files for core and plugins?

I am also a bit contra having all accessible translations in my installation. But: why not? It's some unnecessary files, sure - but that's basically a normal thing when using frameworks. And the translations are not delivered to the frontend and are no big files. And keeping translations at the code would also make it easy for plugins to ship translations in the right version.

But how to bring the translations to the code? At some point we need .mo files, right? So that is nothing someone wants to do directly. For creating the translations something like GlotPress already seems to do a good job. I don't know how GlotPress works - so maybe they have already solved the code - translation - code problem.

[hellofromtonya]

For consideration, here is how Genesis handles their translations:

1. Translate subdomain running GlotPress.
2. A Genesis Translations plugin.

If we start there, we can then build a better translation model to fit Beans and our Community.

I'm not opposed to making a call back to the server to request the translation file upon activation and updates. Locale is part of that equation as well as the WP language itself, i.e. which version is loaded, .en, .fr, etc.

[GaryJones]

• translate.getbeans.io with GlotPress.
• node-wp-i18n for making the pot (see https://github.com/blazersix/satispress/blob/develop/package.json as an example)
• https://github.com/markoheijnen/grunt-glotpress or similar for extracting translations out of GlotPress during release stage, to bundle with the framework.