Welcome to the official blog of the translators team for the WordPress open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project.
This is where we discuss all things related to translating WordPress. Follow our progress for general updates, status reports, and debates.
In order to post to this site, you will need to log in with your wordpress.org account. Your first post may take a while to show up, as it is moderated. Please follow our tag policy when posting.
A release packageRelease packageA release package is a packaged version of WordPress. That is, a ZIP file consisting of WordPress in its entirety, along with PO and MO files for core, the PO and MO files of default themes and Akismet, and any custom changes a locale has. In the past, most locales built their release package using the form in Rosetta’s dashboard.is what you’re used to building using the form on RosettaRosettaThe code name of the theme for the local WordPress sites (eg. bg.wordpress.org is a “Rosetta” site). All locale specific WordPress sites are referred to as “Rosetta sites.” The name was inspired from the ancient Rosetta Stone, which contained more or less the same text in three different languages.’s dashboard. This is a ZIP file consisting of WordPress in its entirety, along with PO and MO filesMO filesMO, or Machine Object is a binary data file that contains object data referenced by a program. It is typically used to translate program code, and may be loaded or imported into the GNU gettext program. This is the format used in a WordPress install. These files are normally located inside .../wp-content/languages/ for coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., the PO and MO files of default themes and Akismet, and any custom changes you have.
Is my localeLocaleLocale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ eligible for automated release packagesAutomated Release PackagesAutomated release packages are release packages of locales that have no custom changes.? #Is my locale eligible for automated release packages?
Do you have custom changes? For the purposes of this exercise, your locale falls under one of these four groups:
You have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale.
You have no custom changes for the current stable version.
You have minorcustom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php.
You have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications.
Here are the details on each:
If you have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale, you do not need to do anything. Your release package will be created automatically for you. An example locale is en_GB.
If you have no custom changes for the current stable version (like 5.2), please ensure you have an empty branches/5.2/dist directory at i18n.svn.wordpress.org. (Having an empty trunk/dist directory does not help you.) You do not need a dist directory if branches/5.2 or tags/5.2 is empty. Your release package will be created automatically for you. Note that there is a difference between /tags/ and /branches/: If you under /tags/ create a directory 5.2, it will only match the main relase, but not later maintenance releases, like 5.2.1. But a directory 5.2 under /branches/ will be used for both the corresponding major version and for any subsequent minor releases under this version.
If you have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php, please ensure these files exist in a branches/5.2/dist or tags/5.2/dist directory at i18n.svn.wordpress.org. (Having your files in only trunk/dist does not count.) Your release package will be created automatically for you. Also note the difference between tags and branches as described above.
If you have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications, you will need to create a package via Rosetta as you have done in the past. For this, We are phasing out the ability to ship any customizations beyond license, readme, and wp-sample-config.php. This means you need to reach out to the WordPress core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to fold your modifications into WordPress core. You can start this process by creating a Trac ticket.
To summarize:
If all you have is a license, readme, and wp-config-sample.php (or no custom changes at all), everything will be automated for you if you follow the instructions above. Both language packs and releaseReleaseA release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. packages will automatically be created. If you are not at 100% at that time, then language packs and release packages will be created when you reach 100%. If you are later modify a translation (to fix a typo, for example), your language pack and release package will be regenerated.
If you have extensive custom changes, you will need to manually create a package via Rosetta as you have done in the past.
If you go to the releases screen on your Rosetta dashboard, you’ll see a new notice that explains what the system thinks your status is.
A new build will be created only if a translation was changed after the latest build. Rejecting and approving one translation within the WordPress project on translate.wordpress.orgtranslate.wordpress.orgThe platform for contributing to the translation of WordPress core, themes and plugins. is all that is needed.
I didn’t prepare my SVNSVNApache 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 wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/.repoWordPress Localization RepositoryThe WordPress Localization Repository at https://i18n.svn.wordpress.org/ is a Subversion repository where official WordPress translations are maintained. See Working with the Translation Repository for details. for a new release in time. Help? #I didn’t prepare my SVN repo for a new release in time. Help?
No worries. First, create your SVN branches/tags. Since a language pack was probably already built, you have to update one translation (see the question above). Your package will be created during the next build window (see above).
Or alternatively: Do a manual build via the release tool on your local site.
Yes. All you have to do is to clear the directory of your locale. With a commit like [i18n-24837] the directory of your locale should only have these empty directories:
.
├── branches
├── tags
└── trunk
└── dist
(The history doesn’t get lost. Your can continue browsing the old files though the revision log.)
