Andrew Nacin 10:49 pm on December 18, 2011
Tags: announcement ( 114 ), core ( 97 )

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? 🙂

#announcement, #core

Zé 10:57 pm on December 18, 2011

~~Big title is big~~ withdrawn
Xavier 11:16 pm on December 18, 2011

Great news! I’ll be able to help wherever I can.
Remkus de Vries 7:28 am on December 19, 2011

This is great news indeed! Even though you’re only mentioning coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. related 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/, I assume this will also cover locale issues related to plugins like BuddyPress, BBPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org. and themes like Twenty Ten and Twenty Eleven?
- Andrew Nacin 2:41 pm on December 19, 2011
  
  Could you elaborate on the specific 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/ issues with plugins and themes?
  - Remkus de Vries 3:41 pm on December 19, 2011
    
    The pain we now have to go through to use a translated version of BuddyPress and BBPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org. 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 19, 2011
      
      Ah, yes. Language packs are a separate beast (and will also begin to be addressed in 3.4). This proposal is particular to 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 of PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php., JS, or CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site..
      - Remkus de Vries 4:04 pm on December 19, 2011
        
        I figured this would be the prelude to the language packs …
Bage 10:22 am on December 21, 2011

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 21, 2011

@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 localizationLocalization Localization (sometimes shortened to "l10n") is the process of adapting a product or service to a particular language, culture, and desired local "look-and-feel." packages. When you change source from “SubversionSVN 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 wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/.” to “translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins.” (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.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ is missing a logo and encoding is not set as UTF-8.
codestyling 5:29 am on May 27, 2012

This is not the complete handling for 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. 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 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/.

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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 multisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. 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.moMO 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/” 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 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Authors they can implement into their code.

I’m sure, there are some other 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/ 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., 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 27, 2012
  
  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.

Translate WordPress

Weekly Meetings

Posting here

Moving Locale-Specific Modifications to Core

Translate WordPress

Weekly Meetings

Posting here

Share this: