Make WordPress Core

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:56 pm on September 26, 2014 Permalink
    Tags: , ,   

    Announcement: 4.1 kickoff meeting this Monday, September 29, at 1400 UTC. This is an unusual time for us that we’d like to try out. The Wednesday meeting (October 1) is still on for 2000 UTC as well.

    Around the world:

    • 10am U.S. Eastern (GMT-4), 7am U.S. Pacific (GMT-7).
    • This is midnight Tuesday for east coast of Australia (GMT+10).
    • If you’re at WordCamp Europe’s contributor day (GMT+3), this will be 5pm.

    More to come with regards to 4.1 over the weekend, but I wanted to make sure everyone saw this (as it was decided at this week’s dev meeting). But please think about what you’d like to work on or what you’d like to see. This comment thread is also open.

    This initial post said Monday, September 28. Monday is September 29, and that’s the day of the meeting.

    • Casey Driscoll 8:05 pm on September 26, 2014 Permalink | Log in to Reply

      I think you got an ‘off-by-one’ there buddy.

    • Marko Heijnen 9:32 pm on September 26, 2014 Permalink | Log in to Reply

      I would like to see more and better support of dealing with images like generate missing image sizes on the fly, zoom support, filters etc. See for some code https://github.com/markoheijnen/Improved-image-editor.

      Also I would love to help out streamlining the taxonomy APIs but no clue what the current status of the roadmap is.

    • Jeff Chandler 10:11 pm on September 26, 2014 Permalink | Log in to Reply

      I found this out thanks to a reader. The text for chat.freenode.net is wrong. It should be webchat.freenode.net http://webchat.freenode.net/ for the web-based client.

      • Andrew Nacin 10:12 pm on September 26, 2014 Permalink | Log in to Reply

        chat.freenode.net is the IRC server. I guess we could link it to webchat.freenode.net.

        • Kim Parsell 1:42 pm on September 28, 2014 Permalink | Log in to Reply

          There is a link to webchat.freenode.net in the blue box at the top of the main page on make/core, in the Weekly Meetings section. Does it need to be added anywhere else?

    • Jeff Chandler 11:07 pm on September 26, 2014 Permalink | Log in to Reply

      Ohh, my bad. That would have been my second guess. Anything that makes it easier to participate!

    • Joseph 2:04 pm on September 27, 2014 Permalink | Log in to Reply

      I see there has been a huge discussion about the “WordPress Heartbeat and heavy admin-ajax.php usage” here http://www.inmotionhosting.com/support/website/wordpress/heartbeat-ajax-php-usage Wish this is easily adjustable with WordPress core.

    • bvl 2:17 pm on September 27, 2014 Permalink | Log in to Reply

      I would like WordPress to be natively be multilingual, with preferably these abilities:

      1. neglectable (performance/storage) impact for non-multilingual sites

      2. makes any plugin or theme – out of the box – multilingual ready as long as it adheres to current (WP 4.0) best practices regarding i18n.

      3. can group posts as language alternatives (needed to quickly find post translations)

      4. if no language is specified on a table row it applies to any language

      5. back-end can be single-language while front-end is multilingual.

      6. regardless of the language set for the back-end, the user can switch the edit-language to any of the supported front-end languages.

      7. slugs are unique per language

      8. promote as best practise: put admin (back-end) specific translations in separate translation files

      The sought after solution would allow the developer for example to define an option, custom field or term to be language specific (default) or not.

      Even if a theme or plugin wouldn’t be built to be multilingual ready it would still be.
      The editing user would simply set the edit language (in admin bar) to the required language and WordPress would automatically retrieve/save the correct data based on the current editing language and the defined language specificness.

      Of course all relevant API functions and hooks would need to incorporate the language into their logic too. For example, this way when a non-multilingual prepared plugin retrieves an option value it would get a language specific value!

      Many theme and plugin developers who only used to and familiar with single language sites don’t understand the need for and problems and needs of multilingual sites. This probably won’t change for the majority of them. They don’t want to put the extra afford in to find out what’s needed and how to implement it. The ones that do are put off by the lack of a standard. With the above proposed solution they wouldn’t even have to! It would work out of the box!

    • Michel - xiligroup dev 7:53 am on September 28, 2014 Permalink | Log in to Reply

      @ bvl and @nacin
      I fully agree with most of your notes about multilingual features. As data-designer, author of free xili-language plugin since more than 5 years based on taxonomy and other core wp features (no new tables, no cookies,…) only cms data model… i can say that few features in WP core (api, filter) (and time) will be necessary to ship an easy to use plugin. Based on the initial data model, this architecture remains reliable during the succession of version since 2.3 to 4.0 and the amazing power of the wp core (loop and UI). But we must be also prudent about the users target – multilingual activated in a simple single instance of WP (targeted by xili-language) or multilingual activated on a multisite installation (purpose of xili-language ms or multipress -MultilingualPress- by a german group.

      More technically for @nacin

      Plugin xili-language was the first to follow the WP data model and to use a taxonomy (language).
      It is because WP and a theme is translation ready that xili-language can works.
      Since more than 5 years, it was an opportunity to discover gradually the core of WP and to use as possible the core available functions especially for the dashboard side or CPT or CT.

      Without commenting yet, I will list below some subjects that can improve internationalization (and bi/multilingual opportunities):
      A) textdomain
      creation of a default text domain for theme:
      Example: default comment form and WP_locale class use default domain and need to be re-instanciated to be core independant and current language dependant.
      Because (recently and not for all) declared textdomain et language files sub-folder are not reliable, plugin continue to detect these datas.

      B) .po / .mo files (theme and plugin)
      as for core since recently, separation of file for frontend and admin sides. Adding a text domain when data saved in options can be translated.

      C) WP_table taxonomy columns in admin UI:
      If you add a column, no problem to adapt the content of a cell.. But first default columns (like description) are not filterable. So impossible to, per example, add a displayed translation.

      D) taxonomy and xili-tidy-tags
      As you can imagine, I read and read again taxonomy.php.
      The original approach, of xili-tidy-tags (one of the three plugins in xili-language trilogy) is that: it is possible since 2009 to create a taxonomy of terms. It is not exactly like alias features used also in multilingual data model. It need few special queries to do that type of grouping/taxonoming of terms… As wished formerly in tracs, I think it can be a very powerful tool if these queries (with good rules) can be incorporated in Core.

      I am ready to work and detail subject by subject here described or those of the internationalisation topic…

  • Andrew Nacin 6:22 pm on September 23, 2014 Permalink
    Tags: , , ,   

    We’ve moved the SVN and Trac firehose mailing lists to lists.wordpress.org, from the legacy lists.automattic.com. If all goes well, we’ll move the rest of them over as well.

    The one side effect is this is likely to break your existing mail filters. The new mailing list emails are wp-trac@lists.wordpress.org and wp-svn@lists.wordpress.org. If you’re using Gmail’s mailing list filters, those would now look like list:wp-trac.lists.wordpress.org.

    For those of you who use Gmail, I’ve also added basic styling to the SVN commit emails. Hooray for reading diffs with red and green. (For those who don’t use Gmail, you’ve already been seeing styling that Gmail strips out.)

    Just a reminder you don’t *need* to use the Trac firehose. You can also subscribe to individual tickets, milestones, components, focuses, new tickets, etc.

    Another note: WordPress.org is now forced SSL. Announcement and details here.


  • Andrew Nacin 3:56 am on September 4, 2014 Permalink
    Tags: ,   

    The props list has been updated on the 4.0 credits page. If you haven’t updated your display name yet, you should totally do that on your support forum profile.

  • Andrew Nacin 7:11 pm on August 21, 2014 Permalink
    Tags: , , ,   

    Introducing plugin icons in the plugin installer 

    WordPress 4.0 comes with a redesigned plugin installer. Just now we’ve added one of the finishing touches to this project — plugin icons.

    Plugin authors, If your plugin is compatible with WordPress 4.0, it only takes a few moments to change a readme “Tested up to:” value to 4.0. Compatibility information is prominently shown in the new plugin installer, so you’ll definitely want to update this value. For your plugin to stand out, you’ll also want to give your plugin an icon. Read on…


    Beautiful, auto-generated icons

    Default icons are generated using the GeoPattern library by Jason Long of GitHub. If you have a banner image, it is automatically sampled to determine the primary color for the pattern, using Tonesque from @matveb. (Cool, huh?)


    Making your own icon

    Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128x128.(png|jpg) and/or assets/icon-256x256.(png|jpg) and you have an icon.

    You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

    We may implement SVG-to-images fallbacks in core for browsers that don’t support them, so if you go the SVG route, I’d suggest also turning your SVG into a PNG. (SVG takes precedence.)

    Jetpack uses an SVG icon:

    Some tips when designing an icon

    • Keep it simple! The Android and iOS Human Interface Guidelines both have some fantastic design tips.
    • Avoid text, especially since these may be seen at smaller sizes in other contexts (and in languages other than English). And because this is an icon, not an ad.
    • Use the right image format for what you’re doing. Don’t use JPGs for simple designs; don’t use PNGs for photos.
    • Optimize your images! Use something like ImageOptim or your favorite web app, CLI tool, etc.
    • Please no WordPress logos. Come up with your own brand. (If you already have a banner image, you likely already have a head start here.)
    • If you haven’t worked with SVGs before, they’re pretty cool. Here’s a tutorial from Chris Coyier.
    • Keep in mind this is an icon for your plugin, not a display ad.

    Some examples

    Akismet, Jetpack, and Hello Dolly already have icons. You can see their assets directories here, here, and here.

    Thanks to the hard work of Alex Shiels (@tellyworth) for implementing this!

  • Andrew Nacin 7:48 pm on July 2, 2014 Permalink
    Tags: ,   

    Here’s where we are on the five goals for internationalization outlined previously:

    1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.

    First pass done in #28577. There is a list of things to do in the ticket, which includes:

    • Improved error handling when the API or filesystem isn’t accessible. Working on this.
    • Bring this to setup-config.php. Working on this.
    • Place browser-based language suggestions at the top. Working on this.
    • Use better markup rather than simple select/option HTML, currently being worked on by @jorbin.

    2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

    This simply requires replacing mu_dropdown_languages() with a new method that handles uninstalled languages gracefully. This is easy to implement and relies on much of the same code as the install process, so it’s simply on hold until that’s done. I’ve also worked out a UX flow with @sonjanyc.

    3. You should be able to search from the dashboard for plugins and themes that are available in your language.

    This is handled on the WordPress.org side. The updated plugins screen will need to pass a new argument to filter by language, and then remove that argument if the user requests showing plugins in any language. We’ll need to hack in readme/description translation support but that’s a small API change and otherwise WordPress.org work, not core work.

    4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

    A script for this is written. While it needs more work, it was used as a test to build 3.9.1 packages, which are doubling as 4.0-alpha testing packages. This does not require changes in core.

    5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    This is ready. A flag needs to simply be flipped in the API.

    Ongoing problems to solve:

    • I have a proposal to type up for how to handle readmes, license files, etc., in both core and plugins. Requires no core changes.
    • No one has picked up the plan to limit the code modifications still done in some locales. This may end up being a July project for me.
    • The relevant APIs we need in core were deployed to WordPress.org. Also, the plugin and theme directories are fully internationalized; we need to get those strings to translators and shoehorn them onto existing international sites.
  • Andrew Nacin 7:41 pm on May 21, 2014 Permalink
    Tags: ,   

    Internationalization goals for 4.0 

    Every few releases we’ve made a major push for improved internationalization. In 3.7, that was laying the groundwork for plugin and theme language packs (more on that soon). In 3.4, it was reducing all of the customizations that many localization teams needed to make. (There’s a page on that here.) In 4.0, I’d like to close the loop on a lot of this. Here’s what I’d like to accomplish, and I’ll need a lot of help.

    1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
    2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
    3. You should be able to search from the dashboard for plugins and themes that are available in your language.
    4. All localized packages should be able to be automatically generated and made available immediately as part of the core release process.
    5. Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    That’s the what. The how poses extensive challenges.

    1) Choosing a language when installing WordPress. The rest of the install process would then be in that language.



    Split workflows: One issue that came up in #26879 (“friendlier welcome when installing WordPress”) is that setup-config.php is often not the initial entry point. A user installing WordPress through a hosting control panel is likely to be dumped onto the install screen (if not the dashboard directly).

    Thus, we need to keep in mind that either screen might be the “intro” screen. This introduces technical challenges: If the user’s first step is setup-config.php, we don’t actually have WordPress fully loaded at this point, which makes actually installing a language pack more difficult. The install step has WordPress loaded in full, just without database tables. We should look into making setup-config.php load “all” of WordPress to make these environments easier to code.

    Different approaches: There are two different ways to approach this: download language files immediately upon selection, or bundle barebones language files of the install screens for all supported languages. The latter is not the easiest thing to do (due to error messages and such, strings can come from all over) and also adds a delay to the adoption of new languages. The former would mean that we would want to pull a languages list from WordPress.org. (If we cannot reach WordPress.org, we would have no way of downloading the complete language pack, so this is not a big deal.) It’s still a bit of a challenge due to the split workflows problem.

    Recommending a particular language: WordPress.org already recommends a language based on the browser’s settings (Accept-Language header) as well as using a more rough lookup based on IP address blocks. (HTML5 location could be used, but unless we’re also going to use that to set the user’s timezone, it seems excessive for a “choose your language” for the moment, especially since location is not as preferred anyway.)

    Both would require the client to hit WordPress.org via JavaScript, versus a server HTTP request. We can do a server-side HTTP request to generate the list, then a client-side request to float recommended ones to the top. It’s possible to do it in two steps: the Accept-Language mapping can be done locally, while the IP-to-location table on WordPress.org has 2.9 million entries and would require a round-trip. Of course, if a user has downloaded a localized package directly from a local WordPress.org site, that would be the top recommendation.

    Note that by language or locale we also must consider other translation variants, as there may be a language like Portuguese available in multiple locales (Brazil, Portugal) and further broken down by formal and informal variants. Each of these would be listed as their own “language.” c.f. #28303

    2) You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.

    WordPress MU had this feature and it still exists in multisite (though it’s pretty broken in terms of how it handles locales, #13069, #15677, #19760). This however only worked for already installed locales.

    For single-site, the available languages should be fetched from WordPress.org and cached in a transient. (#13069 suggests using the GlotPress locale list, but as indicated above, we’d want to handle newly added or updated languages. This can then be displayed in a dropdown on the General Settings page. Upon selection and “Save Changes,” the language pack would be downloaded and enabled. We would likely use the oddly named “WPLANG” option since it’s what MU adopted and uses at both the site and network levels.

    If we can’t reach WordPress.org, or if a filter is applied, then only installed languages will be listed. (An untrusted multisite network will likely have a default filter in place, to match existing behavior.) We should try to cache failures to .org (generally — not just here) so things aren’t terribly slow when developing a site without internet. We could possibly lazy-fetch the list only when the user expands the dropdown (or clicks a “Change” link or something).

    Note this does not address two situations in particular: user-specific languages, or using the dashboard in English. These will be easier to do thanks to improvements in 4.0, but there still exist a number of edge cases where persistent translations can “bleed” into other situations. Examples include a comment moderation email being emailed to an English speaker but sent in the language of the logged-in commenter; or a string stored in the database like image metadata. When using a plugin, these are “edge cases.” When core adopts them, these become “bugs.” We will need to introduce a locale-switching method not unlike switch_to_blog() and also identify and work around any “persistence” issues. Not for 4.0, though we can get started on the groundwork.

    3) You should be able to search from the dashboard for plugins and themes that are available in your language.

    With language packs (more on that soon), plugins and themes will be able to be translated into any language. The goal would then be to have “localized” plugin and theme directories on the translated WordPress.org sites, listing just the plugins or themes available in their language. Note that even a plugin or theme without strings have a name and description that can be translated.

    The plugin and theme install screens in the dashboard should similarly gain this ability. In all cases, there would be an option to expand the search to plugins/themes available in any language, of course — along with the invitation to translate them.

    We will need to figure out how to make readme files translatable, which get parsed for the plugin directory (and eventually themes will gain these as well, possibly as part of these initiatives).

    4) All localized packages should be able to be automatically generated and made available immediately as part of the core release process.

    A localized package should merely consist of core WordPress plus a few translated files (the readme, the license, and the sample config file) and the PO/MO files. No other alterations should occur, which means translation teams will only need to translate, and builds can be automatically generated and made available immediately as part of the core release process.

    Local modifications. Before 3.4, every install needed to make modifications to WordPress as part of their localized package, whether by actually replacing core files or using a {$locale}.php file. By my audit, this now applies to only 14 locales.

    At the very least, we can allow the current system to work as-is for these locales. Ideally, though, we address the specific concerns of each locale and bring as many as possible into the fold. They include:

    • Some CSS modifications we can incorporate into core.
    • Workarounds for declension issues in a few locales, specifically regarding the names of months. #11226, also #21139, #24899, #22225
    • Adding major locale-specific oEmbed providers. #19980
    • Transliteration such as Romanization for Serbian. We can handle this by having two variants of Serbian, the way we have formal and informal European Portuguese. (But we’d automate these language packs, rather than forcing translations to happen twice.)
    • Significant changes in Uyghur (#19950), Farsi, Chinese, and Japanese (including the multibyte patch plugin).

    Additional concerns:

    License. Many locales also have an unofficial translation of the license. We should be able to collect any of these in a repository and include it automatically in a package. (Note that link is an explainer; no GPL version 2 translations are available from that page.)

    Readme. Some locales directly translate readme.html. Others add a second file and use one of two forms: the translated word “readme” (example: leame.html would be Spanish) or using a suffix (“readme-ja.html” for Japanese). We should standardize this somehow. Technically the readme changes with each version due to the version bump, but we can automate that. Bigger readme changes are fairly rare, but we’ll still need to figure out how to have these translated and tracked.

    wp-config-sample.php. This one is especially interesting. If a user has chosen a language on install, we don’t need the readme or license but we do need this file, as setup-config.php will display its contents in a textarea if we’re unable to write the file. We can store this file as a single translated string in a PO/MO file (in some automated fashion) or as part of the API response. We will also need some kind of way to translate and track this file to be included in localized packages that are downloaded.

    5) Localized packages should only be used for initial downloads from WordPress.org. Instead, language packs should be transparently used for updates.

    The WordPress.org API is set up to return a series of update “offers” — one of each type (“latest” a.k.a. reinstall, “update” and “autoupdate”), in both the site’s language and in English. This results in awkward double-upgrades even when no strings have been changed (updating first to English, then to the locale when it is available for that version) and is a lame experience. While auto-generating localized packages immediately will help, there’s no reason to actually use localized packages for updates. Any locale without local modifications can be set up as a language pack now.

    As of 3.7, WordPress core supports receiving instructions for language packs. We’d simply stop issuing localized package offers, start issuing language pack offers, and rip out some code on update-core.php that has been handling the multiple-offer dance. This is the easiest of the five 4.0 tasks but is dependent on the very complex fourth task.

    Next steps.

    Here’s an overall outline of the things we need to do. I’ll be creating relevant core and meta Trac tickets in the coming days, and I’ve also referenced a few related tickets I was able to find.

    Biggest problems to solve:

    • Figure out how to handle readmes, licenses, and wp-config-sample.php. This includes plugin (and theme) readmes as well. Remember we don’t want plugin developers to need to be involved in any way; and also that updates to these files will need to be handled elegantly (such that we have both ‘stable’ and ‘development’ tracks).
    • Eliminate all code modifications across all locales (as much as possible). Related, #20974.

    WordPress.org/API work:

    • Create an API for core to use to fetch available locales for download.
    • Create an API for core to use to recommend a locale based on browser settings/location.
    • Auto-generate localized packages and core language packs.
    • Serve core language packs for updates, not localized packages. Related: #23113, #27164, #26914, #27752.
    • Mirror the plugin and theme directories to locale sites, with full translations (including readme data) and with selective searching.

    Core work:

    • Add the ability to install a new language pack on demand.
    • Add a “switch to language” method, for languages that are installed. #26511
    • Add a screen that allows a locale to be chosen. May need to change how setup-config.php bootstraps WordPress.
    • Add a language chooser to the General Settings screen. #15677
    • Support searching for plugins/themes in a particular language, as well as leveraging translated data fields that come through from the API response. This mostly just means sending back the site’s language to WordPress.org. It also requires UI to reveal results from any languages. We could possibly filter/hide/show on the client side, if results were not paginated.
    • Take a machete to update-core.php’s localized build handling once everything else is done. Related: #25712, #28199.
    • MB Creation 7:47 pm on May 21, 2014 Permalink | Log in to Reply

      Evening Andrew,

      I think the what is awesome. I’ll try to think about and contribute to the how !
      Keep up the good work.


    • Charleston Software Associates 7:53 pm on May 21, 2014 Permalink | Log in to Reply

      Perfect timing!

      I am in the midst of testing an issue with my plugin that occurs when a user is not using English as the native language. Without boring anyone with the details, I found the need to quickly and easily switch from a native German to English version of WordPress to run through my test cycle for the upcoming patches. After the 4th edit of wp-config.php I was thinking “why the heck isn’t there a select language option on the General Settings of WordPress?”.

      Now I know why.

      I am going to talk to one of my lead contributors whom is my go-to “language issues” guy from the Netherlands and see what we can contribute to this endeavor. As I reach out to non-English-speaking customers this is an area we have been focusing on this year.

      Getting things like the up-front presentation, especially readme.txt, is probably the most prominent barrier to acceptance of the plugin in other languages.

      If we can continue the integration of things like WPML hooks, language files, and more localization hooks we may just be ready to attract more international users about the time 4.0 rolls out.

      Looking forward to bigger & better things with WordPress in the coming years!

    • Casey Driscoll 8:58 pm on May 21, 2014 Permalink | Log in to Reply

      This is really well done and thought out Nacin, nice work.

    • glueckpress 9:15 pm on May 21, 2014 Permalink | Log in to Reply

      Given this is huge already the question might be either out of scope, or of perfect timing: can we sneak a post language feature into 4.0? We’ve already been working on a plugin, the only thing is final implementation should happen in `WP_Post` which cannot be extended via plugin. Anyway, here’s what we’ve come up with so far. https://github.com/glueckpress/wordpress-post-language

      Regarding contributions to the roadmap above I’ll be happy to pitch this for the WordCamp Hamburg Contributor Day; as it looks like there’s going to be multipersonal unique language intelligence available.

      • Andrew Nacin 9:56 pm on May 21, 2014 Permalink | Log in to Reply

        I don’t see this as part of 4.0’s roadmap. It’s in the same boat as other things I mentioned like per-user languages, having the dashboard in English, and the like. For the moment, it’s a bit of a case of “cart before the horse,” but I think it makes a great plugin for now and could be considered for inclusion once we’re farther along.

    • terraling 9:21 pm on May 21, 2014 Permalink | Log in to Reply

      Hi Andrew

      Great to hear that internationalization will be getting so much attention with 4.0, but… (there is always a but).

      As is, it is nigh on impossible to make a multilingual site with WordPress. You can have a WordPress install in any language you like, as long as it’s only one language.

      Of course you can, as I have, customise wp-config.php or use plug-ins so that different users can see content on the front-end in different languages, but it’s only surface deep.

      Have someone write a post in English and then someone else who views the site in Spanish comment in pigeon-English on the post, the post author will receive the comment notification email in Spanish.

      It’s as if someone Polish sends you a friend request on facebook and the request email comes through in Polish. (And this is exactly what happens if you set up a multilingual BuddyPress site. Speaking with the developers they say it is pretty much impossible to fix without changes to WP core.)

      I’m not qualified to help make those changes, I’m afraid, but I think they are as important as the steps you’ve outlined above.

      • glueckpress 9:33 pm on May 21, 2014 Permalink | Log in to Reply

        Just think of the possibilities opened by a simple select box that sets a post as being written in a given language … now I’ll quit spamming. 😉

      • Andrew Nacin 9:50 pm on May 21, 2014 Permalink | Log in to Reply

        This post extensively covers this under task #2. See the final paragraph in that section.

        • terraling 8:05 am on May 22, 2014 Permalink | Log in to Reply

          Sorry Andrew, not sure how I missed those details.

          It requires storing a default language setting for each user. Rather than individual plug-ins producing their own solution, it would be great if the where and how could be standardised in core.

          • Andrew Nacin 3:54 pm on May 22, 2014 Permalink | Log in to Reply

            As indicated in the post, there are a lot of issues with doing this for now. If a plugin does it, it’s safe to call them “edge cases,” but once core does it, those edge cases become “bugs.” We would need to fix a number of issues of persistence and context before doing anything in core.

    • michalzuber 3:35 am on May 22, 2014 Permalink | Log in to Reply

      Wow, great. Like the first and second step. How much time did it take to write this, did you have a draft and worked on it? 🙂

      • Andrew Nacin 3:53 pm on May 22, 2014 Permalink | Log in to Reply

        It took about two or three hours to write, but of course we’ve been thinking about these problems for a long time.

    • Rami Yushuvaev 7:37 am on May 22, 2014 Permalink | Log in to Reply

      Nacin, the readme changes with each version due to the version bump is unnecessary. You need to remove the version number from the readme file.

      • Mike Manger 11:02 am on May 22, 2014 Permalink | Log in to Reply

        I think including the version number gives some context to the system requirements and update instructions for the specific version (“If you are updating from version 2.7 or higher”, PHP 5.2.4 is required for version 3.9).

      • Andrew Nacin 3:50 pm on May 22, 2014 Permalink | Log in to Reply

        As indicated in the post, “Technically the readme changes with each version due to the version bump, but we can automate that.” We should keep the version number but make it unnecessary for you to update it.

    • Fernandot 6:02 pm on May 22, 2014 Permalink | Log in to Reply

      Great, great, great!

      and … 


      This have been one of my everlasting wishes 🙂

    • Mariano Perez 6:30 am on May 23, 2014 Permalink | Log in to Reply

      This will bring the software to a higher level. Great decision.

    • Paal Joachim Romdahl 11:04 am on May 23, 2014 Permalink | Log in to Reply

      Thank you for sharing Andrew! In this process are there plans on having the default WordPress phrases on the frontend also change depending on language selected?

      • Andrew Nacin 5:22 pm on May 23, 2014 Permalink | Log in to Reply

        I’m not sure what this is referring to… But yes, the language selection would be equivalent to the WPLANG constant — it would apply to everything (themes, plugins, core; dashboard, frontend).

    • niknetniko 10:14 am on May 24, 2014 Permalink | Log in to Reply

      This is all very nice!

      I have a little question: you’re going to make WordPress download the correct languages pack when the user chooses a language, so: will this apply to plugins as well?

      If you download a plugin from within the WordPress admin area, would it be possible to only download the correct language pack with it?

      For example, if my WordPress installation is in Dutch and I install a plugin, it would download the plugin and only the Dutch language files. The same would happen when you change the language from the options.

    • Nashwan Doaqan 2:10 pm on May 25, 2014 Permalink | Log in to Reply

      Great!! .. Good News!! 🙂
      I will be happy to help you on this..

    • Charles Frees-Melvin 1:24 am on May 26, 2014 Permalink | Log in to Reply

      When dealing with plugins or themes and localizations. It should be added to a GlotPress entry that can be set, to list the fall back language if the prefered localization is not available for the plugin or theme. Like for en_CA to use a en_UK or en_AU before settling with an en_US. Or a pt_BR to settle on using a pt_PT if it exists.

    • Misamee 6:06 am on May 27, 2014 Permalink | Log in to Reply

      Thanks Nacin: the whole post sounds really intriguing!

      I’m working on WPML development and I’d like to keep an eye on three of these changes in particular.

      1. The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
      2. You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
      3. […] language packs should be transparently used for updates.

      As for the first and second points, we may use the WPLANG value as a default language, if define (something that we don’t currently do now).
      Each time this value get changed, WPML would need to know it: I suppose than a simple action would be enough for WPML to get the new information, and set it as a default language, rather than continuously checking if WPLANG got changed.

      As for the third point, if the core, a plugin or a theme gets a new language or an updated language, WPML could use this information (e.g. when user select to handle translations via WPML, rather than via po/mo files). Again, an action would be really helpful.
      Unlike the previous action, here I’m imagining something a bit more specific:

      // string $context: ‘core’ | ‘theme’ | ‘plugin’
      // mixed $data: null | plugin or theme data
      add_action(‘language_pack_downloaded’, $context, $language_code, $data);

      Of course, these are just suggestions: anything that could provide the information that a language pack got downloaded should be enough.

      By the way, there is any way to get all trac items related to the internationalisation changes in 4.0?

    • Amit Kvint 4:22 pm on June 1, 2014 Permalink | Log in to Reply

      Great work, looking forward to enjoying it.

    • Kaspars 8:17 am on June 3, 2014 Permalink | Log in to Reply

      I think you meant localization (l10n) instead of internationalization (i18n).

      • Andrew Nacin 1:12 pm on June 3, 2014 Permalink | Log in to Reply

        Well, it’s a mix. Generally, software does internationalization and translators do localization, as also indicated in the article you linked. Some of our work here does involve making changes to how WordPress is localized (such as integrating locale-specific tweaks) but for the most part internationalization is what’s happening here — making changes so it can later be localized.

    • Torsten Landsiedel 2:25 pm on June 4, 2014 Permalink | Log in to Reply

      @nacin: It would be great if someone have a look at this ticket for WordPress 4.0 again: https://core.trac.wordpress.org/ticket/17268
      This would be really awesome and important for non-english WordPress sites.

    • sonjanyc 10:10 pm on June 9, 2014 Permalink | Log in to Reply

      I’m happy to help with design for this (UI/UX)! After talking to @nacin yesterday, I’ve started working on wireframes and mockups. I’ve put together the flow for the installation process (both for manual WordPress install and 1-click-install).
      Installation flow: http://sonjaleix.com/wp-content/uploads/2014/06/i18n_W4.0_v0.1_flow.jpg

      Ideally we ask the user in the first step of the installation process to choose his/her language so the installation process is already translated. I’m not sure from a dev point of view if we can already install/download the language pack in that stage, but if not, we should at least have all installation screens translated.

      Since we have 135 languages (current list), the dropdown will be pretty long. I like the way apple translated the “Call-to-Action” in the example @nacin posted above, but I think it will be easier for the user to find and select his/her language, if the dropdown list only contains the names of languages. Hence see attached initial mockup.

      Mockup 1: http://sonjaleix.com/wp-content/uploads/2014/06/wp-install_language_select-1.jpg
      Mockup 2: http://sonjaleix.com/wp-content/uploads/2014/06/wp-install_language_select-2.jpg

      Looking forward to getting some feedback.

    • lonchbox 6:20 pm on June 10, 2014 Permalink | Log in to Reply

      This sounds great! :D, also think this option will give us a more accurate data of the real language usage of WordPress. Because most of the spanish language sites use english core 🙂

    • sonjanyc 1:50 am on June 25, 2014 Permalink | Log in to Reply

      @nacin Let me know how I can help pushing this forward on the UX/UI front. Is there a ticket in track for this or all conversation here so far?

    • Victor J. Quesada 8:53 pm on August 6, 2014 Permalink | Log in to Reply

      nice. great!

  • Andrew Nacin 5:52 am on May 6, 2014 Permalink
    Tags: ,   

    Release Candidate for 3.9.1 

    I’ve packaged up WordPress 3.9 RC1 and intend to ship it Wednesday morning. For a complete list of the 33 issues, please see this report. Some highlights:

    • Widgets: Theme preview empties sidebar on active theme. #27897.
    • Multisite: Fixes regressions with uppercase characters in network paths; and with www as a subdomain. #27866, #27927.
    • Header images: Fix weird behavior (or hiding) of various buttons: #28046, #27848, #27936.
    • Performance: Fix potentially slow query on the new/edit post page. #27985.
    • Various playlist, media, and editor fixes, including drag-and-drop text (#27880) and positioning of images when adding a caption (#27922).
    • Some minor internationalization and RTL issues, like #27924 #27893 #27845.

    Note this does not address a number of other issues, which are slated for a 3.9.2 release. Notably, many of these will require updates to TinyMCE, or require additional study or testing.

    Download it here (zip) or grab the latest nightly (here or using the WordPress Beta Tester plugin). Testing strongly encouraged; feedback welcome.

  • Andrew Nacin 5:36 pm on April 30, 2014 Permalink
    Tags: , ,   

    Helen is the WordPress 4.0 release lead 

    Mike and I are pleased to pass the release lead baton to Helen Hou-Sandí for WordPress 4.0. I don’t think this will come as much of a surprise to most of you, but please offer @helen your congratulations, which are well-deserved.

    We’ve already discussed 4.0 a bit in our last two meetings. Expect today’s weekly meeting at 2000 UTC in #wordpress-dev to be the kickoff for WordPress 4.0.

    @DrewAPicture, @wonderboymusic, and @johnbillion have all been renewed for guest commit for 4.0. Additionally, I’m happy to announce that, after more than a year as guest committers, Dominik (@ocean90) and Sergey (@SergeyBiryukov) both have permanent commit access. Their prolific contributions have left a lasting mark on WordPress and I hope to see them at it for years to come.

    A release lead, if anyone is curious, determines all important parameters for a release, like schedule, deadlines, which feature plugins are merged, and more generally, scope and goals. They take point when it comes to meetings, shepherding contributions, announcement posts, and updates. A release lead is a connector and facilitator, identifying bottlenecks and friction wherever they may be and at the service of the developers and plugin teams that are aiming to have something in a given release, and be in frequent communication with them.

    The release lead should should follow what’s being committed, and set the tone for prioritizing and gardening the milestone on Trac. Given the constraint of time in hitting a date, help with prioritization and ensuring good communication lines are two of the most valuable things a lead can contribute.

    The last five release leads were lead developers, but that’s not a requirement, nor is being a committer. I always thought of my “code reviewer” and “committer” hats as being separate, additional responsibilities. (Helen, of course, also wears these same hats.) Regardless: the release lead has the final call on all important decisions related to the release.

    Addendum: For those unaware, for WordPress, version 4.0 sounds like a “big” version number but it’s just another major release for us, like 3.9 and 4.1, constructed over the same ~4-month release cycle. But don’t tell Helen that! Here’s to 4.0 being awesome.

  • Andrew Nacin 5:25 am on April 21, 2014 Permalink
    Tags: , ,   

    Let’s have a meeting in #wordpress-dev on April 21, 2014 18:00 UTC, to discuss WordPress 3.9.1 and triage those tickets. As preparation for the meeting:

    Reception has been overwhelmingly positive and, anecdotally at least, we’ve seen more issues as they relate to deliberately changed aspects (TinyMCE/editing) versus generic plugin breakage. I think we’re in pretty good shape based on the bug reports that have come in, but with automatic updates at our disposal, there’s no reason to wait three or four weeks before shipping 3.9.1.

    I think we should try to fix the big, obvious stuff by Tuesday and release 3.9.1 as early as Wednesday. Some of the reported issues are pretty core to TinyMCE 4.0 and the various rewrites it triggered (like image editing), which means many of them won’t be handled by 3.9.1. That’s quite OK, especially since some of these may require some upstream fixes in TinyMCE, and since there can always be a 3.9.2 in the weeks ahead.

    What I do want to do is have no “unknowns” — we should know exactly what regressed or otherwise is broken, under what circumstances, how major or minor it is, how high or low of a priority it should be, etc. That includes unit tests (if applicable) or at least clear test cases.

    cc @azaozz @helen @wonderboymusic @gcorne @avryl @mcsf @ehg @jeremyfelt @ocean90 @westonruter

    • Andrew Nacin 5:28 am on April 21, 2014 Permalink | Log in to Reply

      If you’re able to look through tickets in your domain ahead of the meeting that would make it go pretty quick, and we can cover them really at any point during the day (I’ll be around all day), I just wanted to make sure the ball gets rolling.

    • Weston Ruter 11:39 am on April 21, 2014 Permalink | Log in to Reply

      Alas, I’ll be in the air at this time. Not sure I’ll have WiFi. I think widget customizer is in good shape for 3.9.1 with critical #27897 being committed and with minor #27878 having a patch.

    • greghall1 9:02 pm on April 25, 2014 Permalink | Log in to Reply

      Hi Andrew,
      Not sure if this is where I should post this info.
      I upgraded two of my WP sites to 3.9 and have lost the thumbnails where I have manually arranged my galleries (this is how I set up the whole of both sites in my Hydra themed greghall.ca & monkeypencollective.com). I cannot add media as I am worried it will destroy my current and desired galleries throughout.
      Greg Hall

  • Andrew Nacin 1:40 pm on April 16, 2014 Permalink
    Tags: , , ,   

    jQuery UI and wpdialogs in WordPress 3.9 

    WordPress 3.9 does not use the “wpdialogs” TinyMCE plugin as part of the TinyMCE 4.0 update ( #16284, #24067), which comes with a new dialog manager. (For more, see this post and their migration guide.) This was a jQuery UI wrapper we had introduced back in WP 3.1. If you were using this in your own scripts, please be sure you are setting “wpdialogs” as a script dependency.

    If you were using jQuery UI for anything on the post screen, please be sure you are setting this as a script dependency.

    In both cases you may need to enqueue the “wp-jquery-ui-dialog” stylesheet, if you are using the WP UI dialog design.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar