Internationalization Internationalization (sometimes shortened to I18N , meaning “I - eighteen letters -N”) is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures, a process called localization. This is the process of making software translatable. Information about Internationalization for developers can be found in the Developer’s handbooks. goals for WordPress 4.0
Hello all. Earlier today I published a post on make/core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. called Internationalization goals for WordPress 4.0. This of course affects you so I wanted to make sure you saw it and give you the opportunity to provide feedback. I am sure you will have questions as to how this will affect translation teams, which you can ask here if you’d like.
Let me outline the goals for WordPress 4.0. I’ll then answer what I anticipate will be some frequently asked questions.
- The first step installing WordPress should be to choose a language. The rest of the install process would then be in that language.
- You should be able to choose/switch a language from the general settings screen, after which the language pack should be downloaded.
- You should be able to search from the dashboard for plugins and themes that are available in your language.
- All localized packages should be able to be automatically generated and made available immediately as part of the core release process.
- Localized packages should only be used for initial downloads from WordPress.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/. Instead, language packs should be transparently used for updates.
Does this mean I will no longer need to create builds and releases?
That’s the idea. If at time of core release you are 100% translated, then I’d want everything to be packaged up automatically. Ideally, the Rosetta The code name of the theme for the local WordPress sites (eg. bg.wordpress.org is a “Rosetta” site). All locale specific WordPress sites are referred to as “Rosetta sites.” The name was inspired from the ancient Rosetta Stone, which contained more or less the same text in three different languages. builder will go away entirely.
The builder will go away? But what about alpha/beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./RC A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. releases?
We’ll make it possible to build these.
What if my locale 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/ doesn’t make any modifications?
Once this goes into effect, you won’t be able to make local modifications anymore. The whole process is being simplified. We’ll be retiring the ability to ship a {$locale}.php file or to add files to dist/. Future adjustments will need to go through WordPress core.
What if my locale currently requires local modifications?
We’re not going to make the experience worse for your users by preventing you from making these modifications. As I noted in the post, about 14 locales 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/ make changes that WordPress core will need to account for first, not including readmes, licenses, and the sample config file. This is going to be similar to my efforts in 3.4 to reduce the number of hacks you needed to make. Once your locale no longer requires modifications, legacy modification support will be disabled for your locale.
So, how are we going to translate readmes, licenses, and sample config files?
I don’t know yet. They will either continue to be done in SVN 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/., incorporated into the Rosetta dashboard, or somehow imported into translate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins.. You won’t need to update the readme with each version, though; we’ll be sure of that.
Does this mean SVN won’t be needed anymore?
The idea is to simplify the entire process down to translation. You shouldn’t need to be a developer, or know how to use version control, or be awake to immediately push a build, or be responsible for issues like this.
What if I want to use SVN still?
I plan to drop support for building packages directly from SVN. This isn’t just simplifying the process. It will also drastically simplify the complex build system behind Rosetta (yes, the rest of it will be open-sourced) and improve maintainability. If you’re one of the three or so translation teams that make liberal use of SVN, I imagine we can work something out. (After all, GlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org. makes it easy to import PO/MO 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/.)
Will this eliminate the double-upgrade annoyances?
You bet. There will no longer be irrelevant “in English” warnings. Automatic background updates will “just work” without leaving you confused.
Do language packs mean I can fix a typo post-release?
Yes! Language packs for core WordPress releases will mean that updating the strings A string is a translatable part of the software. A translation consists of a multitude of localized strings. will be separated from updating the software itself. We don’t typically change strings in a point release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. because it slows you down in shipping a package (which is sometimes a security fix), but we might do that in the future with enough warning. And if you have a typo in a translated string A string is a translatable part of the software. A translation consists of a multitude of localized strings., you could fix it whenever, and the language pack would simply be rebuilt and re-served to installs — no need to wait (or hope) for a point release.
This post mentions plugins and themes, but when is all of that coming?
Basic language pack support is live for a few select plugins (bbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org., BuddyPress, Akismet) and I expect to have a wider pilot program ready in the coming weeks. More details to follow, promise.
Nacin, you forgot about X!
The post and its comments mention a few things that aren’t going to happen for 4.0, like “Admin in English,” per-user languages, per-post languages. (We need to walk before we can run.) If something is missing that should probably be in 4.0, please mention it. Or if I over-simplified something in that post (as in, it doesn’t look like I accounted for how complex something is going to be to do), please enlighten me.
Bonus: How can I help build all of this?
Great question! I’ll be shifting tasks into tickets on both core and meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Tracs in the coming days. If there is something in particular you want to help with, please let me know.
#announcement, #core
