Building the GlotPress Translation Manager

Recent Updates Page 2

An often requested feature in GlotPress has been to be able to support locale “variants”. This has been tracked as issue #226 on GitHub and has been open since January 2016.

Locale variants allows for a “root” language to have one or more “variants” of the language in which the variants automatically inherits the translations of the root for any missing translations.

This is useful for many popular languages, for instance English, Spanish, French, etc. where the vast majority of the translations are likely to be identical with minimal differences for local dialects.

PR #747 has recently been created with a solution for locale variants.

Ok so what does it look like?

The first thing to note that all of the below is based on the current PR, which may change by the time it is actually merged in to GlotPress.

Let’s say you have a project called “Labels”, with three locale’s defined:

English (Unites States)

Spanish (Spain)

English (Canada)

One of these things isn’t like the others, but two of them are very close to being the same.

In the above situation, English (Canada) would inherit the translations form English (United States) for any translations that were not defined.

Going to the translation set page you would see something like this:

You’ll notice a new entry in the legend at the bottom of the page, “Root translation”, this indicates any translation shaded in this color (slightly darker green) is inherited from the root language instead of being marked as untranslated (white).

If you select one of these translations to edit you will see the following editor displayed:

Notice the addition of the “Root Translation” information under the Meta heading along with a link back to the root translation.

If you change the translation here and save it, a new translation entry for the locale will be created and the root translation will no longer be inherited.

Looks good so far, so now what?

The PR is mostly complete, however we are looking for some input on one part of the system; the relationship between root and variant languages.

As part of the PR an initial pass at defining the relationships between languages has been made but we are looking for input from the community to ensure they are correct and for any missing relationship that make sense.

One item to note is that root to variant relationships can only go one level deep, so you cannot define a variant of one root as the root of another one. So in our English example, you cannot do English (United States) -> English (Great Britain) -> English (Canada). This was done on purpose to ensure translations did not degrade in quality as they moved farther away from the original source language.

The current root/variant relationships in the PR (see the locales.php in the PR for full details) are as follows (the root is the top level name and the variants are in the bullet list):

Arabic

Algerian Arabic

Moroccan Arabic

Azerbaijani

South Azerbaijani

Azerbaijani (Turkey)

German

German (Switzerland)

Swiss German

Greek

Greek (Polytonic)

English (Unites States)

English (Australia)

English (Canada)

English (UK)

English (New Zealand)

English (South Africa)

Spanish (Spain)

Spanish (Argentina)

Spanish (Chile)

Spanish (Colombia)

Spanish (Costa Rica)

Spanish (Guatemala)

Spanish (Mexico)

Spanish (Peru)

Spanish (Puerto Rico)

Spanish (Venezuela)

Persian

Persian (Afghanistan)

French (France)

French (Belgium)

French (Canada)

French (Switzerland)

Dutch

Dutch (Belgium)

Norwegian

Norwegian (Nynorsk)

Portuguese (Portugal)

Portuguese (Brazil)

Tamil

Tamil (Sri Lanka)

Chinese

Chinese (China)

Chinese (Hong Kong)

Chinese (Singapore)

Chinese (Taiwan)

A brief note about the slightly strange English root/variants, English (United States) was chosen as the root due to the vast majority of code that is written with it as the language of the source code. The root/variants relationships are assigned during the load of the locales file and can be altered for individual sites either through the use of a custom locales.php (using the GP_LOCALES_PATH define) file or through a plugin that hooks in to the GP_INIT hook.

Feedback on the above relationships (or any other part of the PR) is most welcome as always, you can visit the GitHub Issue or PR to participate.

So what’s the proposal?

This proposal is to fold the 2.4 items in to the 3.0 milestone, add the above “low hanging fruit” design issues to 3.0 and assign 3.0 as the next release for GlotPress.

A tentative timeline for 3.0 would be:

Beta 1: September 5th, 2017

Beta 2: September 12th, 2017

RC 1: September 19th, 2017

Release: September 26th, 2017

There is one additional issue that would have to be opened, as we have merged several PR’s that have an “@since 2.4” already, we’ll have to create a PR to update those items to 3.0. To avoid having to update individual PR’s in the 2.4 tag, the recommendation is to merge all remaining 2.4 items and then just before the beta release, do a single PR to update all “@since” tags from 2.4 to 3.0.

Surly that must be it?

Feedback on the above proposal is most welcome and we will be granting final approval for it at next weeks GlotPress meeting in Slack assuming no show stoppers present themselves.

As always, you can visit the GitHub Issue and PR tracker to participate in any of the above items.

It was a bit quiet the last few weeks and it’s time to get the ball rolling again. We’ll start with our weekly meetings on January 10th at 17:00 UTC. Please mark this date in you calendar and join us in the #glotpress channel on Slack.