Ready to get started?Download WordPress

Translate WordPress

Tagged: announcement Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 4:00 am on August 14, 2014 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    I’ve finally fixed a very broken translate.wordpress.org and pushed 4.0 to http://translate.wordpress.org/projects/wp/dev. There are ~85 new strings, which you can now begin translating. (It should probably go pretty quickly.)

    It’s safe to consider this a “string freeze” — with the exception of the about page, which will be finalized over the weekend.

  • mani_monaj 5:40 pm on July 30, 2014 Permalink | Log in to leave a Comment
    mani_monaj • fa.wordpress.org editor
    Tags: announcement,   

    Guys, I extracted word frequency stats of WordPress 3.9 language files. It can be helpful to internationalization teams to build and prioritize their glosseries. You can find the results here.

  • Andrew Nacin 12:06 am on May 22, 2014 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    Internationalization goals for WordPress 4.0

    Hello all. Earlier today I published a post on make/core 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.

    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.

    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 builder will go away entirely.

    The builder will go away? But what about alpha/beta/RC releases?
    We’ll make it possible to build these.

    What if my locale 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 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, incorporated into the Rosetta dashboard, or somehow imported into translate.wordpress.org. 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 makes it easy to import PO/MO files.)

    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 will be separated from updating the software itself. We don’t typically change strings in a point release 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, 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, 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 Tracs in the coming days. If there is something in particular you want to help with, please let me know.

    • Remkus de Vries 7:17 am on May 22, 2014 Permalink | Log in to Reply

      Looking good @nacin :) Looking very good. I am super excited about what’s up ahead for what’s closing in on 50% of all WordPress users.

      Basic language pack support is live for a few select plugins (bbPress, BuddyPress, Akismet)…

      I’ve seen bbPress and Akismet being updated and getting odd results. I assume this is fixed now?

      Have you thought about scenarios where a (multi)site will have more than one language active?

      • Rasheed Bydousi 7:34 am on May 22, 2014 Permalink | Log in to Reply

        Fonts in English version looks bad in the Arabic version.
        I hope that we will stay have the option to change the fonts type.

        • Gonahkar 8:04 am on May 31, 2014 Permalink | Log in to Reply

          As @Rasheed mentioned above, some languages look ugly in WP’s default font family.
          We really need to change the default font in Persian language too.

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

        @defries As of right now, multisite only runs an update check from the main site. However, there is a filter that allows you to request multiple languages from the API. Example usage would be to request all languages used on any site. Due to the distributed nature of multisite this may be tough to do in core, but we have a lot of opportunity to think about that.

        • Remkus de Vries 8:03 am on May 23, 2014 Permalink | Log in to Reply

          There are a lot of multi-lingual sites that fit this multi-site scenario. Would your thinking be that all those sites should add such filter in order to update all them languages?

    • Nashwan Doaqan 8:37 am on May 22, 2014 Permalink | Log in to Reply

      hmm.. Looks Good!! This will make the translation process more easier!

      1- Is this mean the WordPress package will be without translation files and they will be auto downloaded and generated when the use choose the language from the Installer? if Yes! what if I want to download a local-version to use it offline?

      2- As @Rasheed Bydousi said we shall still have the ability to change the CSS at least! ..

      Thanks for your effort !! ^_^

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

        The standard WordPress package you download from wordpress.org/download/ will be without translation files. However, the package you download from a locale site, such as ar.wordpress.org, will include those languages, and specifically recommend that language during the selection process.

        This package, of course, will not be used for updates; instead, WordPress would use the separate “language pack” that would consist of just PO and MO files. These packs would also be hypothetically available to download, though it’s just the wp-content/languages folder that you’d be able to find in the main package.

    • Xavier Borderie 9:52 am on May 22, 2014 Permalink | Log in to Reply

      “Do language packs mean I can fix a typo post-release? Yes!”


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

      @Rasheed @alex-ye: Once your locale no longer requires modifications and we retire the legacy builder for your locale, you will no longer be able to make CSS modifications. These changes belong in core, not as part of a language pack.

      We handle these issues in one of two ways. One, we adjust the CSS generally to account for longer strings. Two, we have locale-specific rules: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/l10n.css. You can open tickets on Trac (under the i18n component) and any CSS problems can and will be addressed in the next version. We’ve been doing this since version 3.4 and it has been working out well, which is why we are now moving to retiring the local modifications.

      Already, RTL uses Tahoma, except for Hebrew, which uses Arial instead. Some locales also make adjustments to avoid rendering italics. If Tahoma for Arabic is not good, please open a ticket.

  • Andrew Nacin 7:44 pm on October 2, 2013 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    Strings for WordPress 3.7

    Hello, all. I want to explain what was going on with 3.7. After we rearranged our code repositories for WordPress core, our tools that generate and import strings needed to be adjusted. At the time I also knew that a 3.6.1 security release was being prepared, so we moved the “Development” project to “3.6.x” to make sure all 3.6 and 3.6.1 releases went smoothly.

    GlotPress is not yet good at “branching,” so after I move “3.6.x” back to “Development” and create an empty “3.6.x”, I have a script that handles exporting and importing all translations. Once that happens, I can then update the original strings in the “Development” branch to reflect 3.7. If I were to just create an empty “3.6.x” and let you do the export from “Development” and import into “3.6.x”, your exports will be incomplete because the originals changed, and that’s no fun, and it makes it much harder for you to release security releases.

    (Note: This isn’t a complaint about GlotPress. I’ve had conversations with @markoheijnen about how a few adjustments can make GlotPress better for us, and I’m excited.)

    I cited 3.7 repository changes as the catalyst, but we’ve actually done this shuffling previously. No one noticed until now because this release cycle is so short. But, I’ll argue that this “shuffle” is actually a good thing. Otherwise, what happens is a few strings change per week during early “alpha” development, and translators jump all over those. But in reality, those strings are still in flux, which means you’re just doing extra work because GlotPress presented you with a string that we might change in a few days. That’s no fun for anyone, and it makes me feel really bad, because your time is valuable. Waiting a few weeks before we start to populate strings into “Development” is actually ideal.

    Okay, what about string freeze?

    You may have also noticed that 3.7 was a very “low-level” release. It primarily focused on bug fixes, code improvements, and updates. There were no major user-facing features or UI changes, which also meant there were very few strings. there are only around 76 strings new in 3.7. I imported the new strings less than two hours ago, and then I went through each of them to confirm there were no typos or changes to make. The crazy thing is in two hours, two translators are already almost done! (Props @damst and @SteveAgl.) That just goes to show how easy and quick it will be to update your translations for WordPress 3.7.

    It also showed how quickly new strings are translated. As I said, I want to make sure you feel your time is valued. So: let’s consider this point to be a “string freeze” with a qualifier. The 76 strings have been double-checked and are ready to go, and you should start translating them today. The qualifier: There will be some new strings that get added over the next week. First, we’re still polishing a few things. Second, there is also the about page, which I promise you’ll have a week to translate. We’re planning to launch 3.7 the week of October 14, so expect to hear more next week.

    What about language packs?

    The general concept of “language packs” are new in 3.7. But, a lot of the processes for how WordPress.org will be handling those is still not settled (more to come here). However, If you’re looking for something to do, may I suggest you make sure your translations for the WordPress importer plugins are up to date? Upon 3.7’s launch, any 100% translations for these plugins will be delivered to WordPress sites during updates. The same goes for bbPress, BuddyPress, and default themes, too.

    While after reading this you may come to your own conclusion, I promise there was no conspiracy, negligence, or incompetence to keep you all from translating 3.7. :-)

    Finally: If you’re at WordCamp Europe this weekend, please come find me to chat! I want to hear your thoughts and ideas.

    Happy translating!

  • Andrew Nacin 8:01 pm on June 21, 2013 Permalink | Log in to leave a Comment
    Tags: announcement,   

    WordPress 3.5.2 has been released. This is a security release and there are no string changes. Please push new releases asap, thanks.

  • mechanmx 9:05 am on April 17, 2013 Permalink | Log in to leave a Comment
    Tags: announcement, , ,   

    I would like to validate strings in Polish translations for bbpress. There’s a lot to be done and I’m not the only one who need localization for forums in WP.

    Thanks in advance!

  • Andrew Nacin 6:05 pm on November 29, 2012 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    String Freeze

    Strings for WordPress 3.5 are now frozen.

    The targeted release date remains December 5, 2012 (the same date we announced at the start of the cycle).

    Unfortunately, this means I’m very late in formally declaring a string freeze. This is entirely on me and I accept responsibility for the delay.

    With the exception of the About page, we’ve had only a handful of string changes over the last week. Most translations seem to be in fantastic shape this release, which is a great sight to see. I hope all of you are able to step up and push through.

    If you find any typos or other issues, please report them to http://core.trac.wordpress.org/. If you have any questions (or are just plain frustrated with me), feel free to leave a comment.

  • Andrew Nacin 3:07 am on July 12, 2012 Permalink | Log in to leave a Comment
    Tags: announcement,   

    wppolyglots has moved to make.wordpress.org/polyglots!

    Note you’ll now be using WordPress.org usernames here. If there are any issues, let me know.

    All of your existing subscriptions were transferred over (post or comment subscriptions via email, RSS, or Jabber). We also automatically mapped WP.com usernames to WP.org usernames when transferring the posts.

    • Jamàl 6:52 am on July 12, 2012 Permalink | Log in to Reply

      We also automatically mapped WP.com usernames to WP.org usernames when transferring the posts.

      What about if someone had two different usernames on the DOTCOM and the DOTORG?

      Nice move by the way.

      • Andrew Nacin 2:37 pm on July 12, 2012 Permalink | Log in to Reply

        The mapping actually used email addresses to map users, not usernames. Zé and I went through the 50-something users that did not have a corresponding email address and manually looked up WP.org usernames.

        I could not track down the user accounts for a few dozen one-off posts (none from any regular validators/translators that I could identify) — you can find those assigned to the potbot user: http://make.wordpress.org/polyglots/author/potbot/.

    • Milan Dinić 5:52 pm on July 22, 2012 Permalink | Log in to Reply

      Two things:

      • There is an error in a link to wpdevel in the sidebar, it’s not code, it’s core.
      • Can you please install PuSHPress / RSS Cloud plugins since feeds are now very slow updating on Google Reader and not as fast as on wp.com? Probably a good idea would be to enable them network wide.
    • Milan Dinić 1:50 pm on July 23, 2012 Permalink | Log in to Reply

      It looks like there are issues with subscriptions. First thing is that checkbox for subscription to new posts is auto checked for me (I’m not subscribed). Maybe this is intentional but I’m reporting it anyway.

      Yesterday I left comment above and one on make/systems. In both cases I unchecked post subscription and checked comment subscription (100% sure), and for both places I got email to confirm following of those two blogs (i.e. posts). I haven’t received notification about your comment and on subscribe.wp.com there aren’t this two posts in list for comment subscription but there are this blogs on “waiting” list for post subscription.

      And comment subscription is unchecked here right now .

  • jenialaszlo 8:18 pm on April 20, 2012 Permalink | Log in to leave a Comment
    Tags: announcement, ,   

    Jetpack 1.3 will be released in a couple of days, and the Automattic team would love it if you could help out with translations, especially Spanish, Portuguese, French, German, Italian, and Dutch (all regional flavors welcome :) ).

    The GlotPress project has already been preloaded with translations pulled from WordPress.com and previous Jetpack versions. There are 465 strings in this release, and many languages are already above 50%.

    There is a slight chance that a couple of strings will change before the release, as 1.3 is still going through the final testing. We’ll post a note here if that happens.

    If you would like to have a language added to Jetpack and/or or want to be assigned as a validator for your language (especially if you already validate WordPress translations), please leave a comment and we will help you out.

    Thanks in advance for your help!

    • Gabriel Reguly 1:11 am on April 21, 2012 Permalink | Log in to Reply

      Hi Jenia,

      Did some more translations for pt_BR, but GlotPress is not behaving well with this translation:

      ↵ Sent by a verified %s user.

      It issues this error message, event if I just do ‘Copy from original’

      Warning: Original and translation should both begin on newline.

      Follows link: https://translate.wordpress.com/projects/jetpack/1.3/pt-br/default?filtersstatus=either&filtersoriginal_id=43569&filterstranslation_id=1420177


    • SteveAgl 5:41 am on April 21, 2012 Permalink | Log in to Reply

      Can add the wordpress validators as me for jetpack too? thanks

      • Jenia 3:12 pm on April 23, 2012 Permalink | Log in to Reply

        Ciao, I added you as the validator for Jetpack 1.3 in Italian. Thanks for your help!

    • Wacław J. 6:39 am on April 21, 2012 Permalink | Log in to Reply

      Is it possible to set per-project validators?

      • Jenia 3:09 pm on April 23, 2012 Permalink | Log in to Reply

        You bet. There can be different validators per project or per sub-project (e.g. someone can be a validator for WordPress.com but not Jetpack, or be a validator for Jetpack 1.2 but not 1.3). Why? :)

        • Wacław J. 12:09 pm on May 1, 2012 Permalink | Log in to Reply

          How do I do that?

          • Jenia 1:23 pm on May 1, 2012 Permalink | Log in to Reply

            You need to be able to grant validator permissions, i.e. be a GlotPress admin for that install. In case of Jetpack in particular, someone from Automattic (me, for example) can assign different validators per project. If you need help with that, just let me know (although I am not sure why you would need that, since only the active translation project of Jetpack is important).

            • Wacław J. 1:33 pm on May 1, 2012 Permalink

              Great to know that. Thanks. :)

    • Carlos Eduardo G. Barbosa 1:56 pm on April 21, 2012 Permalink | Log in to Reply

      Can you include, please, Sanskrit (sa_IN) with me as validator?
      I am working on Sanskrit for WordPress 3.4, and it would be nice to have Jetpack plugin translated also.
      Thank you.

    • Carlos Eduardo G. Barbosa 2:13 pm on April 21, 2012 Permalink | Log in to Reply

      The string ‘Resore this item from the Trash’ is mispelled. Please correct it.

    • Martin (IQ) 11:35 pm on April 23, 2012 Permalink | Log in to Reply

      What are freedom levels? Could you explain what is meant with that in order to find a good translation. :)

      • mdawaffe 12:55 am on April 24, 2012 Permalink | Log in to Reply

        The publisher of a VideoPress video may flag the video to never use flash: the video may only be played in an HTML5 video capable browser.

        If your browser does not support HTML5 video, that “freedom levels” message is shown.

        The link is to http://www.gnu.org/philosophy/free-sw.html

        • mdawaffe 12:56 am on April 24, 2012 Permalink | Log in to Reply

          I agree it’s not a very helpful error message :)

          • Martin (IQ) 2:18 am on April 24, 2012 Permalink | Log in to Reply

            I agree. :) And it’s a translators nightmare as well. I’ve checked several translations (with the help of translate.google.com) and found not one that made sense to me. Indeed, I would go so far as to say that a lot of them are translated completely wrong and in a misleading way.

            What this error message basically wants to say is “Your browser doesn’t support HTML5 video playback”, right? So why not just saying this? I know it’s tempting to mention some gnu philosophy here and there but why do you give us translators such a hard time?

            • mdawaffe 8:21 pm on April 24, 2012 Permalink

              Technically it’s “The author of this video has decided it may only be played using non-proprietary technology. Your browser must support HTML5 video playback (an open technology) to play this video”.

              The intention was not to give translators a hard time. The intention was to promote open technologies. It’s just badly written.

              The string isn’t going to change for this release of Jetpack.

            • Martin (IQ) 11:01 am on April 25, 2012 Permalink

              Thanks for clarification. This helps at least to find a better translation. :)

            • Martin (IQ) 11:05 am on April 25, 2012 Permalink

              btw. the translations of “freedom levels” I’ve found range from “plains of freedom” to a very free translation of “you’re not authorized”.

    • KardiWeb 10:27 am on April 24, 2012 Permalink | Log in to Reply

      Hello Jenia,

      I would like validators to request access to the hungarian translation.
      Thank you

    • KardiWeb 5:31 pm on April 24, 2012 Permalink | Log in to Reply

      Username: idesignsmedia and no kardiweb. please repair.

    • mdawaffe 10:58 pm on April 24, 2012 Permalink | Log in to Reply

      Jetpack 1.3 is about to launch. Thanks so much for all your time and efforts. We really appreciate it.

      We’re happy to launch 1.3.x releases to improve translation, so please don’t let this 1.3 release stop you from contributing if there’s more to do in one of your languages :)

    • Wacław J. 9:03 am on May 3, 2012 Permalink | Log in to Reply

      Can you set me as a validator for Polish?

  • Andrew Nacin 2:55 pm on April 20, 2012 Permalink | Log in to leave a Comment
    Tags: announcement, ,   

    A release of version 3.3.2 is imminent. There are no string changes. This is a security release, so please release as soon as possible.

    An important note. One, you can still build from SVN, there is requirement to use GlotPress at this time. Two, I made numerous changes to many locale’s /dist folders — the folder at i18n.svn.wordpress.org where we pull readme.html, wp-config-sample.php, etc. — in preparation for 3.4. You are going to want to use your 3.3 branch or tag for /dist if that is the case. (I made branches for you if they didn’t exist.)

    So: Check to make sure you are using the right /dist.

    You can check the changelog to your SVN directory here: http://i18n.trac.wordpress.org/log/pt_BR (change pt_BR to your locale folder). And browse yours here: http://i18n.trac.wordpress.org/browser/pt_BR.


    If there are any issues, post here, and I, Zé, and others will do my best to resolve them.

    • Gabriel Reguly 3:04 pm on April 20, 2012 Permalink | Log in to Reply

      Thanks for the heads up.

    • Rasheed Bydousi 10:33 pm on April 20, 2012 Permalink | Log in to Reply


    • Gabriel Reguly 1:11 am on April 21, 2012 Permalink | Log in to Reply

      pt_BR is released.

      As a side note, we use tags for the builds.

      Yet, I had a look at branch 3.3 and seemed to me tha it was originally 3.1.1 ?!?! Is that correct? Should not it had come from 3.3.1?

    • Bage 4:37 am on April 21, 2012 Permalink | Log in to Reply

      ta_LK has been released.

      We also used tags to build it.

    • Mark Thomas Gazel 9:03 pm on April 22, 2012 Permalink | Log in to Reply

      I might need some help here. Or som e pointer.

      Using the repo-browser in Tortoise I can’t access the dist-folder for 3.3.1. Get this error:

      PROPFIND of ‘/!svn/vcc/default': could not connect to server

      So should I take the dist-folder from either branch og tag 3.3 and put in an 3.3.2-folder. And then reuse the messages-folder from 3.3.1 and put it in the 3.3.2-folder also?

    • Gabriel Reguly 2:54 am on April 27, 2012 Permalink | Log in to Reply

      Today I have found that pt_BR was broken for themes.

      For the build, I have selected the usual (for me) option:

      translate.wordpress.org (dist/ files will still be taken from Subversion)

      But because the GlotPress files were empty, the build got no translations. Yet they where present at Subversion.

      I had the same issue for 3.2.1, instead that time it was the opposite: the strings where not present at Subversion, but at GlotPress. So that time I built from SVN.

      I wonder which would be the recommended option for building 3.4, will it use GlotPress as suggested?


  • Andrew Nacin 5:02 pm on April 4, 2012 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    I think we are going to turn off the SVN builder for 3.4.

    You will still be able to use your SVN directory, and we will continue to pull files from /dist (like readme.html and wp-config-sample.php). But, in order to create a build, you will need to import any po/mo files you have into the wp/dev projects at translate.wordpress.org.

    GlotPress is all about collaboration. So others may help, it is preferred that you periodically import your po/mo files there (if you work with a separate tool), rather than importing them at the end in order to do a release. This also isn’t just about collaboration. At some point, I’d like to make it so you can mark your locale as “ready” for a release. Then we will simply create the build for you when we release WordPress.

    • Gabriel Reguly 5:29 pm on April 4, 2012 Permalink | Log in to Reply

      Hi Nacin,

      That is great news.

      But please test the GlotPress build option thoroughly before disabling the option do use the SVN builder.

      See, it was not working well for both 3.3 and 3.3.1, so I had to make the pt_BR build using the SVN option.

    • Xavier 10:44 pm on April 4, 2012 Permalink | Log in to Reply

      Can’t say I’m too thrilled about this move. But while I don’t see how it it necessary to make us use GlotPress as the One Tool (import questions aside), I can’t say I wasn’t seeing this coming sooner or later.

      • Andrew Nacin 11:18 pm on April 4, 2012 Permalink | Log in to Reply

        It is necessary because:

        There are many things we have in mind that make more sense if they were centralized in a single web-based tool (and that’s coming from someone who loves Subversion and uses it every day).

        For example, files like wp-config-sample.php and readme.html could become managed through an screen in Rosetta, rather than via Subversion. Ideally, you should not need SVN at all to manage a translation — that’s the end goal here. Also, we are now sending a number of strings into POT files that aren’t actually strings, like timezones, character vs word counting, and more. I would like to make those appear differently in GlotPress. I am already monitoring these values with simple database queries, and with GlotPress, we can even do things like special validation and views.

        When we begin to expand to crowdsourcing the translation of plugins and themes, we’re going to continue to expand our use of GlotPress. SVN will not be involved. It can’t scale in the technical sense and more importantly when it comes to learning curves and barriers to entry. We should all be using the same product and be on the same page. (As you said, it was going to happen sooner or later.)

        Another thing is to consider security and validation, to help ensure that bad or broken things don’t get into strings. If it goes through GlotPress, we can evaluate everything on a string-by-string basis and it all sits nicely in a database. If it goes through Subversion, we cannot. This is very important especially as we begin to open up translate.wordpress.org to plugins and themes.

        And so I ask, why aren’t you thrilled about this move? I understand this will change your workflow in particular (even if all you need to do is import a few PO files, which will take 2 minutes). So I would appreciate some specifics, as maybe I can help.

        • Xavier 9:53 pm on April 9, 2012 Permalink | Log in to Reply

          Oh, no worries, I hear your points loud and clear, as I do Zé’s, and completely understand that comes a time when you need to focus your energy on the most manageable and accessible tool, which SVN clearly is not for newcomers.

          As you said, this is more a question of workflow: I for one like to use Poedit (and even donated to the project :) ), and the GP interface just doesn’t do it for me. As such, I’d hate to see SVN support go the way of the dodo, but again, I’m sure this time will come.

          So, while I’m an old man who sees his world start to crumble, I do sincerely welcome the forward-looking thinking behind this decision, and support it. I also am glad to see you Andrew taking care of our ageing community. Go youngsters! :)

      • 12:06 am on April 5, 2012 Permalink | Log in to Reply

        You also have to keep in mind that the profile of people willing to donate their time to translating WordPress isn’t necessarily one that has a working knowledge of SVN. Granted, many of us do, but the reason for that is both historical and fading away, i.e. in the beginning the ones translating were very often developers who needed a localized version, and even if they did not know SVN, they were familiar with the mindset required to learn it. As the number of languages and audience of WordPress grows, so is said profile shifting more towards those interested in the language itself and less in the underlying technology.

      • Mattias Tengblad 1:04 am on April 5, 2012 Permalink | Log in to Reply

        I’m with Xavier here.

        But taking Nacins post into account, I do agree with his points, just don’t think we’re there yet.

        Has there been one release where GP has not been screwing things up? Since I follow all the discussions here I’ve seen all the questions/problems with GP on release day and there for I have never used it as a source when building packages (never been any problems using SVN).

        I really want to see a well worked trough GlotPress software and an integration with the locale sites before this is happening. I don’t see GlotPress as a stable enough software yet.

        • Andrew Nacin 1:23 am on April 5, 2012 Permalink | Log in to Reply

          GlotPress does not handle release packaging. Rosetta does. And it is the same codebase, and largely the same code, that handles builds from both GlotPress and SVN. As you agree with my points, you understand why it makes sense for us to choose GP as the One Tool (as Xavier put it).

          I’ve seen just as many questions on release day about SVN. Please point me to a GlotPress or Rosetta problem that is unresolved and I will fix it. (I’m serious.)

          You guys finally have a developer who is invested on a nearly daily basis to ensure that GlotPress and Rosetta not only work, but work consistently. (That’s me, howdy!) They’re not going anywhere, so pull up a chair — we’re going for a ride. :-)

          • Mattias Tengblad 1:36 am on April 5, 2012 Permalink | Log in to Reply

            Just tried to build a package with the new changes http://wppolyglots.wordpress.com/important-changes-for-wordpress-3-4/ not working…

            Standardnyckeln i dist/wp-config-sample.php matchar inte $wp_default_secret_key i sv_SE.php. Nyckeln i sample config är:

            och den angiven i sv_SE.php är:

          • Mattias Tengblad 1:56 am on April 5, 2012 Permalink | Log in to Reply

            What I meant was that if you where using the translations from GP it screwed things up. In other words the relation, GP Rosetta ;) If those bugs are all fixed, then nice :)

            Things that needs fixing in GP:

            Loading a GP page takes ages.
            Fuzzy strings, not working at all in GP.
            Changes between versions needs to get automated, especially since importing seems to bug from time to time. Exporting -> importing between versions isn’t user friendly.

            (Maybe a bit OT, I would love to see GP as a plugin, kind of like bbPress)

            • Andrew Nacin 2:06 am on April 5, 2012 Permalink

              Loading particular pages take ages. It has been on my list to take a look. However, the slowest pages are ones that give a heads-up display of all translation sets, rather than a page that a single translator reasonably needs to be fast.

              Nothing prevents you from using your tool of choice to take advantage of fuzzy strings before GlotPress supports them. It’s just that instead of committing your PO file when you are done, you import it into GP.

              I am not aware of importing bugs. If you have an issue with importing, send me the PO file and I will test.

              I agree, changes between versions is totally lame. I am going to try to write a CLI tool that I can use to migrate all translation sets.

              GP was written as a standalone app, and it makes sense to remain that way. There really isn’t any reason to re-architect it, except to overcomplicate it and use up valuable developer time.

            • Andrew Nacin 9:16 pm on April 5, 2012 Permalink

      • Cátia Kitahara 7:10 pm on June 20, 2012 Permalink | Log in to Reply

        Lately I haven’t helped the Brazilian translation team and Gabriel has been the responsible for the releases, so I’m sorry if I’m saying something stupid. I’m back to it now, I helped translate the last release. But what I feel, is that our translation lost quality because we don’t proof read anymore. I used to do this job with a friend every new release, and we did that with poedit. We split the strings between us, like I did strings 1 to xxx and him from xxx to the end. With GlotPress this process isn’t possible. We tried to split the pages by their numbers, but then some people without admin permission sent their suggestions and them the page numbers were augmented so we didn’t know anymore which ones were lacking proof read. I don’t know if this is me, maybe I don’t know how to use GlotPress in an efficient way, but I feel it is hard to use. I don’t think a project which is already translated should receive new suggestions, unless a validator admin wanted to change things in the whole translation. I’d like to be able to make only the new strings available to receive suggestions. Last release we had a problem with a string which in older versions was correct and now it is wrong. I don’t know what happend but somewhere in the process somebody suggested a wrong translation to something that was already translated before and this new wrong translation got approved. I think GlotPress is too focused on making the process a mechanical thing, while there’s a long way to become a good translation tool. We have our own glossary and it would be awesome to be able to search the translation for inconsistencies and to integrate this glossary to it, rather them having google translator which is useless, (at least for us, the translations suggested are awfull). Other improvement it lacks is to show the same string just once with all the suggestions to it, rather them to multiply it for each suggestion. It just makes our work as validators a nightmare. I know I can see all the suggestions to a string, but I need to click on it. It’s not efficient. And I think this could end the problem of the augmentation of page number. As a validator, I’d like to have control of which strings shouldn’t receive suggestions anymore. I’d like to see better level of role and capabilities. I’d like to setup a team of trusted translators with permissions to discard suggestions, but not with permissions to approve. I’d like to have a comments area where translators could discuss the best suggestions, etc. So, I really think it’s easier to do all this with poedit. You’ll say that I can do that and just import the po to GlotPress, but it’s hard to maintain, I can’t control if somebodyelse will send another suggestion meanwhile and make me have to proof read again.
        So, I don’t know. I’m not very happy with it.

    • Akerbeltz 10:11 am on April 5, 2012 Permalink | Log in to Reply

      For my part, I *am* thrilled – I’m one of those people good at translating but pretty much useless at doing code and the less hair everyone uses having people like me blunder around in svn and suchlike, the better. I don’t see why it shouldn’t work, after all, projects like LibreOffice use such an approach for a very large number of languages too.

    • Naoko 5:19 am on April 11, 2012 Permalink | Log in to Reply

      Now that we (Japanese team) built 3.4 beta 1 package, I realized that the method using GlotPress is missing one important feature: specifying the POT version and corresponding translations.
      Currently GlotPress only tags version by 3.2.x, 3.3.x, and so on. This means there is no tags for beta, alpha, RC, and point-release versions for translation files.

      We have been manually creating PO/MO to make sure the original POT version is the latest one for the creation of each WP core tag. Else we could end up with discrepancies between the latest GlotPress strings and that of the package we are trying to build, depending on the timing of the build.

      • Andrew Nacin 3:44 pm on April 11, 2012 Permalink | Log in to Reply

        This is a good point, Naoko. I am wondering, though, do you foresee this affecting major and minor releases? We will move wp/dev to wp/3.4.x upon release, and were we to do another 3.3 minor release, wp/3.3.x would be current (we haven’t changed a string in a minor release in a while).

        So, I only see this affecting alpha, beta, and RC. In which case, I am wondering if it is necessary. For us, a beta or RC package is nothing more than a snapshot in time. There is nothing wrong with releasing r20426 (HEAD) rather than the exact revision for 3.4-beta1. Anyone updating using the beta testing plugin would also not be getting the exact revision; it goes through the separate nightly build process.

        I think it’s an interesting aspect, but I just don’t know how important it is. What do you think?

        • Xavier 9:16 am on April 12, 2012 Permalink | Log in to Reply

          Most excellent point from Naoko.

          I do think it is important for translators to be able to release test package based in any arbitrary revision, if only to be able to tell local trusted users to test a version before the final release. We’ve done that in the past on our blog: “Help us proofread the translation!”

          There used to be official POT files for beta and RC versions a long time ago (http://svn.automattic.com/wordpress-i18n/pot/tags/), but the tradition has been lost, so translators now have to hope that the POT they are translating against does indeed match the revision they are building their test archive against.

    • Lopo 2:27 am on June 1, 2012 Permalink | Log in to Reply

      I don’t know if you have this in mind but having a similar link to how support forums work today for plugins/themes would be great.

  • Andrew Nacin 8:48 pm on January 27, 2012 Permalink | Log in to leave a Comment
    Tags: announcement,   

    In GlotPress, you may need to export 3.3.x/ms strings and import them into dev.

    For 3.4, we’re changing how we split strings into multiple pot files. Since 3.0, we’ve done a generic POT and then a second POT for multisite. We are now going to be doing a frontend POT, an admin POT, and a network admin POT. The projects have been added to GlotPress here and here.

    While merging and splitting projects in GlotPress, some strings got orphaned. Before you go re-translate all of the missing strings, first go to translate.wordpress.org/projects/wp/3.3.x/ms, export a po file, and import it into both wp/dev/admin and wp/dev/admin/network. Everything should be back to normal.

    Cheers, and sorry for the trouble. For more, see ticket 19852.

  • Andrew Nacin 10:49 pm on December 18, 2011 Permalink | Log in to leave a Comment
    Tags: , announcement,   

    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? :-)

    • 10:57 pm on December 18, 2011 Permalink | Log in to Reply

      Big title is big withdrawn

    • Xavier 11:16 pm on December 18, 2011 Permalink | Log in to Reply

      Great news! I’ll be able to help wherever I can.

    • Remkus de Vries 7:28 am on December 19, 2011 Permalink | Log in to Reply

      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 19, 2011 Permalink | Log in to Reply

        Could you elaborate on the specific locale issues with plugins and themes?

        • Remkus de Vries 3:41 pm on December 19, 2011 Permalink | Log in to Reply

          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 19, 2011 Permalink | Log in to Reply

            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.

    • Bage 10:22 am on December 21, 2011 Permalink | Log in to Reply

      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 Permalink | Log in to Reply

      @nacin Could you please take a look at these?

      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.

      And, i18.trac.wordpress.org is missing a logo and encoding is not set as UTF-8.

    • codestyling 5:29 am on May 27, 2012 Permalink | Log in to Reply

      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 27, 2012 Permalink | Log in to Reply

        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.

  • Andrew Nacin 10:46 pm on December 12, 2011 Permalink | Log in to leave a Comment
    Tags: announcement, ,   

    3.3 is about to be released.

  • Andrew Nacin 6:21 am on December 12, 2011 Permalink | Log in to leave a Comment
    Tags: announcement, ,   

    Expect a final release of WordPress 3.3 in the next 10-36 hours.

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