WordPress Polyglots

Tagged: announcement Toggle Comment Threads | Keyboard Shortcuts

  • mechanmx 9:05 am on April 17, 2013 Permalink | Reply
    mechanmx
    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 | Reply
    nacin
    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 | Reply
    nacin
    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 | 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 | 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 | 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 | 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 | Reply
    jenialaszlo
    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 | 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

      Regards,
      Gabriel

      • Zé 2:01 am on April 21, 2012 Permalink | Reply

        Reproduced. Even if you insert a newline in the translation, it gets stripped. Hence it’s both a GP issue (stripping the newline) and a Jetpack issue (why does a string need to start with a newline character, to begin with?)

      • mdawaffe 12:51 am on April 24, 2012 Permalink | Reply

        I removed the leading newline from the source and copied the translation of the previous string to the new one.

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

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

      • Jenia 3:12 pm on April 23, 2012 Permalink | 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 | Reply

      Is it possible to set per-project validators?

      • Jenia 3:09 pm on April 23, 2012 Permalink | 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 | Reply

          How do I do that?

          • Jenia 1:23 pm on May 1, 2012 Permalink | 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 | 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 | Reply

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

    • Martin (IQ) 11:35 pm on April 23, 2012 Permalink | 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 | 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 | Reply

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

          • Martin (IQ) 2:18 am on April 24, 2012 Permalink | 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 | Reply

      Hello Jenia,

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

      • Jenia 11:52 am on April 24, 2012 Permalink | Reply

        KardiWeb, you’ve been added as a validator – thank you very much for your help!

        • KardiWeb 5:17 pm on April 24, 2012 Permalink | Reply

          Kedves Jenia, nagyon szépen köszönöm a segítségét!

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

      Username: idesignsmedia and no kardiweb. please repair.

    • mdawaffe 10:58 pm on April 24, 2012 Permalink | 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 | Reply

      Can you set me as a validator for Polish?

      • Jenia 1:01 pm on May 3, 2012 Permalink | Reply

        Sure, username waclawjacek added as a validator for Jetpack – Polish.

  • Andrew Nacin 2:55 pm on April 20, 2012 Permalink | Reply
    nacin
    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.

    And: TEST YOUR BUILDS.

    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 | Reply

      Thanks for the heads up.

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

      Done.
      Thanks.

    • Gabriel Reguly 1:11 am on April 21, 2012 Permalink | 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 | Reply

      ta_LK has been released.

      We also used tags to build it.

    • Mark Thomas Gazel 9:03 pm on April 22, 2012 Permalink | 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
      (http://i18n.svn.wordpress.org)

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

      Regards,
      Gabriel

  • Andrew Nacin 5:02 pm on April 4, 2012 Permalink | Reply
    nacin
    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 | 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 | 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 | 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 | 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! :)

      • Zé 12:06 am on April 5, 2012 Permalink | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | Reply
    nacin
    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 | Reply
    nacin
    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? :-)

     

    • Zé 10:57 pm on December 18, 2011 Permalink | Reply

      Big title is big withdrawn

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

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

    • Remkus de Vries 7:28 am on December 19, 2011 Permalink | 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 | Reply

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

        • Remkus de Vries 3:41 pm on December 19, 2011 Permalink | 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 | 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 | 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 | Reply

      @nacin Could you please take a look at these?
      http://wppolyglots.wordpress.com/2011/09/27/please-do-something-about-the-horrible-cache-function/
      http://wppolyglots.wordpress.com/2011/05/16/hello-i-was-building-a-new-beta1-version/
      http://wppolyglots.wordpress.com/2011/11/26/hello-i-just-noticed-that-untranslated-messages-arent/

      Also, there is one annoying bug when building localization packages. When you change source from “Subversion” to “translate.wordpress.org” (or the other way around) option “WordPress branch” grays out and, when you click a button to build a package, you get “Invalid source…” error.
      http://pokit.org/get/?311a03b788899de5f47a9d2aef238b79.png
      http://pokit.org/get/?15a764bd5d2e0f3d1e990ba95398ce3b.png

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

    • codestyling 5:29 am on May 27, 2012 Permalink | 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 | 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 | Reply
    nacin
    Tags: announcement, ,   

    3.3 is about to be released.

     

  • Andrew Nacin 6:21 am on December 12, 2011 Permalink | Reply
    nacin
    Tags: announcement, ,   

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

     

  • Andrew Nacin 7:51 pm on September 12, 2011 Permalink | Reply
    nacin
    Tags: announcement, ,   

    The showcase is now a post type. It’s pretty self explanatory for how all of that works. Just head over to the Showcase screen. (Same permissions as posts: Contributors, Authors, and Editors can all access the screen.)

    For now, whatever ends up in “Description” is not visible, but since Title and Description are now two separate fields, you should go ahead and start splitting up the title field (all existing data was imported) as you may find it to be applicable.

    We’ll introduce a separate /showcase/ page soon.

    Props Zé for writing the core of the plugin. :-)

     

    • Andrew Nacin 7:54 pm on September 12, 2011 Permalink | Reply

      “you should go ahead and start splitting up the title field” — I’ll add the description field to Quick Edit to make this a bit easier to handle.

    • Peter Westwood 10:28 am on September 13, 2011 Permalink | Reply

      It looks like old entries didn’t migrate over for the en-gb site – is this a bug or have I got to remember what I added and add them again?

      • Rami 12:01 pm on September 13, 2011 Permalink | Reply

        same for he_IL, the old showcase sites are gone and the new post type is empty.

      • Andrew Nacin 2:30 pm on September 13, 2011 Permalink | Reply

        Looking into where my migration didn’t work. No data was destroyed so it’s all fixable.

    • Kenan 11:13 am on September 13, 2011 Permalink | Reply

      Same on bs_BA for old entries. It seems that shuffling of sites in Showcase doesn’t work anymore. Now it always displays last three added sites.

    • Rami 12:38 pm on September 13, 2011 Permalink | Reply

      Andrew, it would be nice to have a showcase template page.

    • Mark Thomas Gazel 9:13 am on September 14, 2011 Permalink | Reply

      Will this showcase feature be available as a plugin at some time? In the regular repository.

      I would like to use it elsewhere.

      Are the screenshots live updated or just made once and for all?

      • Andrew Nacin 3:03 am on September 15, 2011 Permalink | Reply

        The screenshots use the mshots API. Gets cached, but refreshed over time as far as I know.

        I can probably release a plugin once it’s farther along. It’s really, really basic, though.

  • Andrew Nacin 7:40 pm on July 20, 2011 Permalink | Reply
    nacin
    Tags: announcement,   

    The charts for WP.com Stats are working again on Rosetta. Also now uses the new chart style (Flot, rather than Flash).

     

    • herzcthu 3:12 am on July 22, 2011 Permalink | Reply

      I can’t find any site stats in my_MM Rosetta. Is it JetPack ? Do I need to request to install Jet Pack on my_MM rosetta site?

      • Andrew Nacin 6:13 am on July 22, 2011 Permalink | Reply

        Looks like some newer sites don’t have Stats hooked up. I’ll take care of it soon.

    • Wacław J. 3:01 pm on July 22, 2011 Permalink | Reply

      Very cool, cheers!

    • Rami 11:01 pm on July 25, 2011 Permalink | Reply

      Lookes good.

  • Andrew Nacin 10:26 pm on July 19, 2011 Permalink | Reply
    nacin
    Tags: announcement, , ,   

    Validators are now controlled through Rosetta

    Editors of Rosetta sites can now control who the validators are for their language. GlotPress will use these permissions across all projects on translate.wordpress.org. You no longer need to post validator requests here.

    Validators are users of that locale’s Rosetta site having the role of Editor, Author, or Contributor. You can also use the new role of Validator (otherwise equivalent to Subscriber). I’ve ported over all existing validators.

    Editors can now add and promote users, as well as edit the theme’s screenshots and navigation menu (Themes > Custom Header and Menus, see previous post). All administrators are now editors instead.

    With this change, we’re also dropping support for locales that do not have a Rosetta site. This applies to 21 languages*, all of which are inactive anyway. GlotPress will no longer function properly for these languages, and a future cleanup will likely remove them from SVN and elsewhere.

    (* – Affected languages are: br, gd, kk, ku, lt, mn, no, pa_IN, zh, az, bn_BD, en_GB, es_CO, fo, haw_US, is_IS, kn, ky_KY, lb_LU, ta_IN, ur.)

     

    • Zé 10:30 pm on July 19, 2011 Permalink | Reply

      Keep in mind that the most immediate effect of this is that you cannot have a locale on GlotPress without the corresponding xx.wordpress.org site, as that site is the *only* place where validators are defined. If your language is missing please post your request on this blog and we’ll take care of it asap.

      • Andrew Nacin 10:32 pm on July 19, 2011 Permalink | Reply

        Yeah, the 21 languages affected were those with at least one validator. Other languages might also be affected, but that means we don’t have a validator (or the language).

        • Gabriel Reguly 10:34 pm on July 19, 2011 Permalink | Reply

          Hi Nancin,

          Please see coment below.

          Thanks,
          Gabriel

          • Andrew Nacin 10:38 pm on July 19, 2011 Permalink | Reply

            It’s Nacin, not Nancin, and you don’t need to talk to me through Zé, I’m right here.

            You are not br. You are pt_BR. br is the internal GlotPress slug for Breton (per ISO 639-1). If they ever request a subdomain, they’ll be bre.wordpress.org.

            • Gabriel Reguly 10:55 pm on July 19, 2011 Permalink

              Hi Nacin,

              First, sorry about misspelling your surname :P

              Zé is our kind helper, I have the bad habit of getting his help every time.

              Also it seemed to me that he could explain my issue better than me.

              Still, we have br.wordpress.org and our locale is pt_BR.

              Maybe I misread Zé’s comment, but I am under impression that we might have needed to have pt_BR.wordpress.org, instead of our current br.wordpress.org.

              Thanks,
              Gabriel

            • Andrew Nacin 10:56 pm on July 19, 2011 Permalink

              Nope, you’re good. :-)

            • Gabriel Reguly 10:57 pm on July 19, 2011 Permalink

              Great, thanks.

      • Rami 10:56 am on July 25, 2011 Permalink | Reply

        Hi ze, i am a he_IL validator (for all wp.org projects in hebrew), but i can’t aceess to my he.wordpress.org account. i see that he_il language was not affected.

    • Gabriel Reguly 10:33 pm on July 19, 2011 Permalink | Reply

      Oi Zé,

      Please talk to Nancin, as we have br.wordpress.org, but our locale is pt_BR.

      Obrigado,
      Gabriel

    • pavelevap 10:47 pm on July 19, 2011 Permalink | Reply

      Great! Two questions:
      1) Any chance to limit some validator rights to specific projects? If there are users with role Validator and they were limited to one project, they can access all projects now?
      2) Can we setup new projects, for example cs_CZ for bbPress?
      P.S. I can see that SergeyBiryukov is user of cs_CZ? It is probably any mistake?

      • Zé 10:50 pm on July 19, 2011 Permalink | Reply

        1) and 2) Not at the moment
        PS-Sergey is ru, so probably a mistake. Feel free to remove him.

        • pavelevap 11:01 pm on July 19, 2011 Permalink | Reply

          Ad 1) That is a little problem. We need to allow for example BuddyPress for some users, but do not want to let them change other projects.

          Yes, I would like to remove Sergey, but it is not possible.
          There is also user swienczyk, but we do not know him and now he can validate everything. Is it possible to know when this user was added and for which project? Thank you.

          • Zé 11:04 pm on July 19, 2011 Permalink | Reply

            I’ve removed Sergey and swienczyk and will look into the issue

            • pavelevap 11:14 pm on July 19, 2011 Permalink

              OK, thank you. I also doubt about converting all current users. I remember there was validator (he is not active) for Android project, but he was not converted (not visible between Rosetta users).

            • Andrew Nacin 11:16 pm on July 19, 2011 Permalink

              swienczyk was the validator for the Android project, I just confirmed.

            • pavelevap 11:18 pm on July 19, 2011 Permalink

              OK, thank you! Mystery solved :-)

          • Andrew Nacin 11:29 pm on July 19, 2011 Permalink | Reply

            Editors can now remove users. Forgot about that part.

      • Sergey Biryukov 3:10 pm on July 20, 2011 Permalink | Reply

        P.S. I can see that SergeyBiryukov is user of cs_CZ? It is probably any mistake?

        Yep, some time ago I registered as a subscriber on cs.wordpress.org. I can’t remember the exact reason though, probably to test WordPress with Czech language files, which are available without registration anyway.

    • Xavier 11:11 pm on July 19, 2011 Permalink | Reply

      Excellent integration! Kept looking for a dedicated Validators menu, when the obvious stroke me :)

      Thanks!

    • گناهکار 12:36 pm on July 20, 2011 Permalink | Reply

      Are they (validators, editors) have SVN access too?

    • Xavier 10:22 pm on July 20, 2011 Permalink | Reply

      One question, now that my head has rested: one validator was known to me, but isn’t part of the WPFR translation team (he does translation for BuddyPress). Another one of the validators is totally unknown to me.

      So, question: does the current list encompass all translate.wp.org validators for a given language, regardless of the project? If so, does my changing their role change their rights on the project(s) they’ve been working on?

    • Mark Thomas Gazel 7:30 pm on August 3, 2011 Permalink | Reply

      Great work Andrew. Wonderful. I have a question though.

      Where were the users ported from? In da.wordpress.org there are now 18 users.

      3 Editors (former validators)
      2 Validators
      13 Subscribers

      I know the three Editors. They are the former Validators of WordPress. All fine. I think the two Validators are validators in the BuddyPress projects. And they are now language-wide. All fine too.

      As for the 13 Subscribers – I have no idea. Don’t recognize any of them. They have no priviliges but I would still like to know how they ended up on the list.

      • Mark Thomas Gazel 8:43 pm on August 3, 2011 Permalink | Reply

        Oh, now I see:

        “You can also use the new role of Validator (otherwise equivalent to Subscriber).”

        So i guees the two “validators” have no priviliges and can’t validate strings.

      • Andrew Nacin 1:28 am on August 5, 2011 Permalink | Reply

        No Subscribers were added during this transition. I think it had to do with when Rosetta was on older versions of MU. You can remove them.

        Edit: Sorry, I hit Reply too early. Validators are equivalent to subscribers as it pertains to Rosetta (WP) access. As the name indicates, they *can* validate. The role simply offers you the ability to give someone validator privileges without providing them Rosetta posting/management permissions. Hope that makes sense.

  • Andrew Nacin 8:56 pm on July 14, 2011 Permalink | Reply
    nacin
    Tags: announcement, ,   

    We’re working on some Rosetta updates. Here’s the first two: Menus and Screenshots.

    You no longer need to request a deploy for Rosetta screenshots. Instead, you should now use the Custom Header feature under Appearance. The size is limited to 466px by 303px, the same width we use on WordPress.org.

    You no longer need to use the Rosetta menu editor under Tools. You can now go to the Menus feature under Appearance. You are limited to top-level menu items, as before.

    Screenshots needn’t be committed to svn anymore as they won’t be deployed. I’ll be phasing out the old menus system soon. It took me three minutes to switch over pt_PT and I don’t even understand Portuguese, so it’s quite easy.

     

  • Andrew Nacin 9:04 pm on May 23, 2011 Permalink | Reply
    nacin
    Tags: announcement, ,   

    The WordPress Credits page (wp-admin/credits.php, new in 3.2) shows the list of translators for the active locale. There are a few things you need to know:

    • There is a string “Translators” with the context of “Translate this to be the equivalent of ‘English Translators’ in your language for the credits page Translators section”. Please do as requested.
    • The names are pulled dynamically from GlotPress. It is designed to show anyone who has contributed an approved string for the current release. (If something doesn’t feel right, let me know.)
    • Please update your display name in your WordPress.org profile. It will use this if present, but please note that UTF-8 characters are not currently allowed. (Known limitation.) The data is cached both in core and on the API server, so updates won’t be immediate.

    Happy translating,
    Nacin

     

    • Milan Dinić 10:35 pm on May 23, 2011 Permalink | Reply

      Thank you!

      The names are pulled dynamically from GlotPress. It is designed to show anyone who has contributed an approved string for the current release. (If something doesn’t feel right, let me know.)

      There are translators who are the only one working on their language and who use SVN only, so it would be better to also include validators from GlotPress too, or those who committed on SVN for that locale.

      But even GP thing doesn’t work perfect, I import PO files in it (which means strings are approved since I’m validator) and I’m not shown.

      And one bug: if there are no translators, there shouldn’t be ‘translators’ slug in API response (as in en_US) since there will be errors “Warning: array_walk() [function.array-walk]: The argument should be an array in wp-admin/credits.php on line 100″ and “Warning: shuffle() expects parameter 1 to be array, string given in wp-admin/credits.php on line 101″

      • Andrew Nacin 10:48 pm on May 23, 2011 Permalink | Reply

        SVN will not be supported. I would argue that the reason why they’re the only person on their language is because, in part, they’re not working in the open with GlotPress.

        I’ll look into supporting strings you import, thanks.

        I’ll check on the bug. In which locale are you seeing the warnings?

        • Milan Dinić 11:02 pm on May 23, 2011 Permalink | Reply

          In which locale are you seeing the warnings?

          sr_RS

          I would argue that the reason why they’re the only person on their language is because, in part, they’re not working in the open with GlotPress.

          Every language is on GP and anyone can submit translations. But that doesn’t mean that there will be community around that translation project. Many languages are small and one can’t except that in all of them there will be many people working on it since translating WP nowadays requires a lot of work and knowledge.

          • Andrew Nacin 6:13 pm on May 24, 2011 Permalink | Reply

            The warnings are fixed – the API was returning invalid data.

            In the end, the strings need to be in GlotPress. In your case, you’re importing them. That will be supported. Pure SVN will not.

      • Remkus de Vries 12:14 am on May 26, 2011 Permalink | Reply

        Now thát is a cool feature. I just checked to see what that looks like, but I think a seperation between a list of Validators follewed by contributors would look even better. I don’t how this is with other languages, but in our case the validators do the bulk of the work …

        • Andrew Nacin 1:10 am on May 26, 2011 Permalink | Reply

          Thought about that, but I’m not sure if it’s necessary. Not to discount the work of the validators, but our contributors are all listed together, whether they’ve submitted a single patch to fix a typo, or dozens of major code contributions.

    • Remkus 1:16 am on May 26, 2011 Permalink | Reply

      Necessary is a big word, but greatly appreciated, yes! Having the validators in plain sight would also help in making that person / team more visible to the dedicated user group and isnt’t that what the credits page is all about?

      • Mattias Tengblad 12:43 am on May 27, 2011 Permalink | Reply

        +1

      • herzcthu 3:44 am on May 27, 2011 Permalink | Reply

        At least, should be visible user avatar of validator as in core developer group and show as validator in bracket.
        And one thing is all names in contributors list and translators list are very close to each other. It is not looking good and difficult to see clearly. Should be some space in each name.

      • Peter Holme 3:43 pm on May 27, 2011 Permalink | Reply

        +1, will make it easier to spot who’s responsible for releases as well (I’d guess)

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel