Sync translations between Dev and Stable projects

On The platform for contributing to the translation of WordPress core, themes and plugins., when a translation is approved in the development part of the project, it is automatically synced to the stable part.
Surprisingly, though, this doesn’t happen when the translation has been rejected: It had to be manually rejected in the stable project as well which caused some confusion.

Today, we deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. an update to this where now also rejections are synced. This means that translation editorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles: General Translation Editor and Project Translation Editor are now relieved from having to reject a translation both in development and stable.

Below is a screenshot that shows a translation in ‘Current‘ status on Stable

The above Current translation was rejected in the Stable part of the project(see screenshot below):

The rejected translation is synced to the Development part of the project as shown below:

#development, #stable, #sync, #translation

Hello everyone Today I erased the translated strings…

Hello everyone!

Today I erased the translated stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. Georgian language for developer branches and begin from a scratch.
There was a lot of translation errors and inconsistencies.
In late June, the translation will be ready.

#development, #ka_ge

Orginazed or not?

At times I don’t think things work to good here @ polyglots. Very much feels disorganized and poorly thought through, which then confuses us who translate and create local packages. Especially since we went from SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the released code are all centrally managed through SVN. to GlotPressGlotPress GlotPress is the translation management software that powers More information is available at

Can we please have a new Development trunk…

Can we please have a new Development (trunk) project @ glotpress

When 3.6 was released someone renamed the current dev project to 3.6.x without creating any new dev project. If we are to move to GlotPress and phase out SVN, things has to work better.

I’ve pointed this out several times, but unfortunately nothing has changed. When we use SVN, we can, in a sense manage tags/branches ourselves, something we can’t do with GlotPress. We are instead dependent on someone taking care of the projects. When 20 days goes by with no response to your request you lose the will to even try.

I even tried to contact the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team via IRC, the third attempt nacin replied, quite vague:

I’ve seen the thread. There will be a 3.7 project once it makes sense.

Firstly, if a request is read, leave a message, I do not have Jedi mind powers. Secondly, when it makes sense to whom? Sorry, but It feels like everyone does as they themselves find fit at the time, not a good way to get things organized…

There are already new stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. for 3.7. Some of us want to work at our own pace and not get all strings at once. Suppose also that a language team wants to review parts of the translations for the upcoming version without involving sub versions aka have access to a development version. Shouldn’t it be possible (just like core)? We should be able to have the ability to organize and plan within our team, without technical limitations. Right now GlotPress is such limitation, at least as long as you have to chase people to get answers to questions/requests that we should be able to ask right here.

This is exactly what I said would happen when discussions about GlotPress came up. GlotPress was and is not ready for this type of project. I think GlotPress can be really good and I will say nothing about evolution that occurs with GlotPress (some are doing a really good job with the updates of the software). GlotPress should be a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party that the teams could operate ourselves on the local sites. It would solve a lot of problems, it would be ready when a local site is set up, and we would be able to manage all projects and users within the teams, in one place.

You may think I’m just ranting, let it be so. When it comes to projects and computers, I am extremely organized, sometimes maybe too organized (if you can be?).

Polyglots, the use of GlotPress and creation of packages need to be reviewed and organized!

#development, #glotpress, #polyglots