Moving Locale-Specific Modifications to Core
Moving Locale-Specific Modifications into Core
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 files, po files, and readme.html.
What does that mean? All plugins, locale.php files, JS, CSS, 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 Trac. 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 locales.
- #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? 🙂