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? 
Zé 10:57 pm on December 18th, 2011 Permalink |
Big title is bigwithdrawnXavier 11:16 pm on December 18th, 2011 Permalink |
Great news! I’ll be able to help wherever I can.
Remkus de Vries 7:28 am on December 19th, 2011 Permalink |
This is great news indeed! Even though you’re only mentioning core related locale, I assume this will also cover locale issues related to plugins like BuddyPress, BBPress and themes like Twenty Ten and Twenty Eleven?
Andrew Nacin 2:41 pm on December 19th, 2011 Permalink |
Could you elaborate on the specific locale issues with plugins and themes?
Remkus de Vries 3:41 pm on December 19th, 2011 Permalink |
The pain we now have to go through to use a translated version of BuddyPress and BBPress is not cool. It’d be great if this whole translation pack thing also included language for – particulary – two two plugins, but for instance, also the Twenty Ten, Twenty Eleven (and future Twenty Twelve) themes.
Basiscally.. in an ideal world, whatever we translate on translate.wp.org for whatever end product, should be made available in an easy fashion for Joe Q. Public.
If you need more input – because if have it if you need it – just let me know. You’ve got my Skype details
Andrew Nacin 4:00 pm on December 19th, 2011 Permalink |
Ah, yes. Language packs are a separate beast (and will also begin to be addressed in 3.4). This proposal is particular to locale-specific modifications of PHP, JS, or CSS.
Remkus de Vries 4:04 pm on December 19th, 2011 Permalink |
I figured this would be the prelude to the language packs …
Bage 10:22 am on December 21st, 2011 Permalink |
In Tamil most of the time the “slug” get trimmed because of the character limitation. I hope this will happen to most of the languages using utf-8 characters.
Is there anything can be done to fix this?
Kenan Dervišević 1:20 pm on December 21st, 2011 Permalink |
@nacin Could you please take a look at these?
http://wppolyglots.wordpress.com/2011/09/27/please-do-something-about-the-horrible-cache-function/
http://wppolyglots.wordpress.com/2011/05/16/hello-i-was-building-a-new-beta1-version/
http://wppolyglots.wordpress.com/2011/11/26/hello-i-just-noticed-that-untranslated-messages-arent/
Also, there is one annoying bug when building localization packages. When you change source from “Subversion” to “translate.wordpress.org” (or the other way around) option “WordPress branch” grays out and, when you click a button to build a package, you get “Invalid source…” error.
http://pokit.org/get/?311a03b788899de5f47a9d2aef238b79.png
http://pokit.org/get/?15a764bd5d2e0f3d1e990ba95398ce3b.png
And, i18.trac.wordpress.org is missing a logo and encoding is not set as UTF-8.
codestyling 5:29 am on May 27th, 2012 Permalink |
This is not the complete handling for locale specific modifications. Let me explain an example from german special needs. It’s common use to have 2 distinct translations of the same source base: formal and informal type of *.mo files.
But there is no build in support at WordPress at all for such a kind of modifications. I would prefere to modify WordPress language handling to cope with this as standard instead of letting plugins like woocommerce going their own way and loading this 2 types on user demand from different folders.
This leads to homebrew implementations not standardized and plugins/themes will start either to copy this behavior or to implement their own way copying with this. Serveral misbehavior will follow asap.
To avoid that and also have a solution valid and common use for all (WordPress Core, Plugins and Themes) following additional changes should be made:
1.) deprecate the usage of WPLANG constant at wp-config.php file and replace it with the same type of usage introduced for multisite installations. Let the user choose it at the backend settings either its multisite or not. For single WordPress installations at a dedicated language just extend the initial database setup to pre-insert (update) the locale at the option table during install.
2.) extend the backend settings to have a checkbox (or more flexible a selectbox) to choose the type of locale file to use if available. This should provide something like “formal”, “informal” ect. and should default to the current behavior at loading language files.
Currently a WordPress file will be loaded by creating the filename as “/wp-content/languages/de_DE.mo” but respecting the new user option for types it could also load “/wp-content/languges/de_DE-formal.mo” file and default back to the standard locale file, if type based file is not available.
3.) extend all the load_textdomain based functions to cope with the type of locale file. This will ensure, that we have a standard way how locale specific types of language files can be easily used by blog owners and also gives a common WordPress standard for all Theme and Plugin Authors they can implement into their code.
I’m sure, there are some other locales also would be happy, if the could load different types of language files for the same locale. It could also as extended as a plus on top with a filter, that can enlarge the available types of language files for the choice list.
Please let me know, if you think, this would also make WordPress more straight forward, common defined and more flexible. In my opinion it reduces the support requests, defines the standard ways and avoid growing homebrew solutions within plugins/themes.
Remkus de Vries 8:15 am on May 27th, 2012 Permalink |
Never gave it that much thought and even though we have chosen to go with the informal version of Dutch for our translation, we do have the same issue. There are numerous sites out there in Dutch that now have to use the informal translation, but really would be better of with the formal one (think government sites for example). So a +1 from me.