Moving Locale-Specific Modifications to Core

Moving LocaleLocale Locale = 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/-Specific Modifications into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

The core team is intending to propose for 3.4 that all locale-specific modifications get moved to core. Ideally, this will reduce all (or nearly all) packages to mo filesMO files MO, 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/, po filesPO files PO files are human readable files which contain translations we use. These files are not used by WordPress itself. Each language will have its own PO file, for example, for French there would be a fr_FR.po file, for german there would be a de_DE.po, for British English there might be en_GB.po., and readme.htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites..

What does that mean? All plugins, locale.php files, JS, CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site., etc., will all end up getting a complete review and become part of core. Any future changes will then take place with new versions of WordPress, and will be tracked on core TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. Translation teams will still advise on, and ideally drive, any needed changes.

I think it’s pretty clear as to why we’d like to go in this direction. This will happen in parallel with language packs. To get there, we will need to simplify the contents of localized packages. The end goal is to make things simpler for the user, but it also can set the stage for future features, and there are added benefits. One, the core developers will be investing time into problems that translation teams face. Two, translation teams will be prevented from solving complex problems on their own.

We know that in some cases, core tickets for certain problems have rotted for some time, forcing hacks, filters, and plugins. We will not only addressing these, but by tackling these issues, we are making a commitment that extends beyond WordPress 3.4 that localized builds are a major player in the ecosystem.

This is a major undertaking, and we will need your help.

I would like to keep discussion here and pure implementation on Trac. However, to demonstrate how serious we are, and how large the scope of this project will be, here is an incomplete list of Trac tickets assigned to the project:

  • #8759 — “Word count” should could by characters in some localesLocale Locale = 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/.
  • #6425 — Support RTL in feeds.
  • #19597 — Allow translation of the bundled plugins’ descriptions.
  • #19598 — Text inputs for codes or URLs should be LTR.
  • #19599 — Localizations should not need to worry about the default secret key.
  • #19600 — Core should know which languages are RTL.
  • #19601 — Support localized defaults for options, links, dashboard widgets, etc.
  • #19602 — Curly quotes from wptexturize() should not be forced on all locale.
  • #19603 — Support locale-specific modifications in core (the catch-all ticket).

I am going to need to have discussions with the fa_IR, ug_CN, ru_RU, zh_CN, ja, and eo locales, as you have complex bundled plugins and locale.php files. Some other locales may have particular concerns as well. We should schedule some public chats in #wordpress-polyglots for this, and to I intend to do a town hall style discussion on #wordpress-polyglots in a few weeks.

Dion Hulse (dd32) is the other core developer on this project, and one of our rockstar contributing developers (and Russian maintainer) Sergey Biryukov will be heavily involved as well.

So, any questions or comments? 🙂

#3-4, #announcement, #core