Updates from Andrew Nacin RSS Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 9:19 pm on May 11th, 2012 Permalink | Reply
    Tags:   

    Browse Happy!

    Hello everyone — WordPress runs a site called Browse Happy, which you’ve probably seen, at http://browsehappy.com/. Here’s a bit about it:

    Using an outdated browser makes your computer unsafe. Browse Happy is a way for you to find out what are the latest versions of the major browsers around. You can also learn about alternative browsers that may fit you even better than the one you are currently using.

    The theme is fully internationalized and I would like to offer it in as many languages as possible.

    Like WordPress.org does when directing you to a locale site, Browse Happy will be able to detect your browser’s preferred language and then offer you the ability to view the site in that other language. We will also do either a subdomain or a path to allow direct-linking to a local site (so de.browsehappy.com or browsehappy.com/de/).

    You will then be able to link to the localized version in core. Browse Happy is only 29 strings, so I hope to launch with a few languages next week!

    Here is the project on translate.wordpress.org. Let me know if you have any questions. Happy translating!

     

    • jiehanzheng 9:43 pm on May 11th, 2012 Permalink | Reply

      Done. By the way, you might also wanna take a look at the word counting issues on Trac.

      • Andrew Nacin 9:58 pm on May 11th, 2012 Permalink | Reply

        Thanks! Yeah, we have been discussing the two tickets during our daily IRC conversations.

    • David Decker (@deckerweb) 11:25 pm on May 11th, 2012 Permalink | Reply

      Hi! I just translated all German strings – ready for approval :)

    • Diana 12:52 am on May 12th, 2012 Permalink | Reply

      Portuguese-Brazil is ready :)

    • Bage 5:16 am on May 12th, 2012 Permalink | Reply

      Tamil(Sri Lanka) is ready :)

    • SteveAgl 10:57 am on May 12th, 2012 Permalink | Reply

      Italian version ready to launch :)

    • Sergey Biryukov 11:28 pm on May 12th, 2012 Permalink | Reply

      Russian version is ready.

    • Naoko 3:56 am on May 14th, 2012 Permalink | Reply

      Japanese is done too :)

    • Andrew Nacin 5:05 am on May 14th, 2012 Permalink | Reply

      I have deployed all completed translations — pt_BR, ru_RU, pt_PT, bs_BA, it_IT, hr, ja, zh_CN, en_CA.

      Thanks everyone! If your browser has an Accept-Language header (which should be most of you), it should work when you go to http://browsehappy.com/. If that doesn’t work, please let me know.

      You can also go to http://browsehappy.com/?locale=ja (for example) — this is what will occur from a localized install of WordPress starting in 3.4.

      • Bage 5:25 am on May 14th, 2012 Permalink | Reply

        Tamil (Sri Lanka) ta_LK also has been translated. Why it hasn’t been included?

    • Diana 5:56 am on May 14th, 2012 Permalink | Reply

      The translation is working here. Also I corrected some misspelling :( …Could you please re-deploy pt_br?

    • Bage 7:14 am on May 14th, 2012 Permalink | Reply

      Please re-deply ta_LK too as I have corrected few words. Thank you.

    • Emre Erkan 9:47 am on May 14th, 2012 Permalink | Reply

      tr_TR is done. Ready to deploy. :)

    • Zé 9:47 am on May 14th, 2012 Permalink | Reply

      pt is working. Notes:

      • From what I can see, the GP locale isn’t being used, i.e. for Portuguese (Portugal) to show up, I have to add ?locale=pt-pt, instead of ?locale=pt, like everywhere else
      • The “Brought to you by” string exists in GP, but is an image on the site (always english)
      • pt needs redeploy (minor fixes)

      • Andrew Nacin 3:23 pm on May 14th, 2012 Permalink | Reply

        Yeah, I noticed the “Brought to you by” — will be working on it with @hugobaeta.

        ?locale=pt was loading pt_BR, but I messed up the deploy for pt_BR last night, so you were getting English. I fixed pt_BR, and fixed how guessing works, so locale=pt means it will now detect pt_PT.

        • Zé 3:28 pm on May 14th, 2012 Permalink | Reply

          It’s important to establish that ‘pt’ means Portuguese and that every other variation of pt_* is exactly that, a variant. We’ve been at this since the 14th century, we’re not about to give it up now :D (and now let the brazilians fume. go!)

        • Andrew Nacin 3:35 pm on May 14th, 2012 Permalink | Reply

          Yes, locale=pt loading pt_BR was a definitely a bug. :-D The guessing code is now fixed, so values of pt-pt, pt_PT, pt, etc., should all load Portuguese, and only pt-br and pt_BR loads Brazilian portuguese.

          • Zé 3:38 pm on May 14th, 2012 Permalink | Reply

            This is an old jab at the way Apple lists languages, i.e. Portuguese and Portuguese (Portugal). There are whole forum threads of people angry at the insult :P

    • Gwgan 9:56 am on May 14th, 2012 Permalink | Reply

      Welsh version cy-GB is ready.

      • gwgan 7:42 am on May 15th, 2012 Permalink | Reply

        I’ve made some usability improvements and sorted some typos to the Welsh translation. Could you upload again, pleas. Thanks.

    • Isaac Keyet 11:25 am on May 14th, 2012 Permalink | Reply

      Swedish done.

    • Coen Jacobs 11:52 am on May 14th, 2012 Permalink | Reply

      Provide a first run on the Dutch translation. :)

    • Milan Dinić 2:04 pm on May 14th, 2012 Permalink | Reply

      Serbian done.

    • Andrew Nacin 3:16 pm on May 14th, 2012 Permalink | Reply

      Deployed ta_LK, tr_TR, pt_PT, cy_GB, sv_SE, sr_RS.

      Still waiting for validator approval for Dutch and German.

    • Diana 4:28 pm on May 14th, 2012 Permalink | Reply

      I think pt_br site is using pt_pt :S

    • Andrew Nacin 4:41 pm on May 14th, 2012 Permalink | Reply

      nl_NL deployed.

    • Milan Dinić 6:32 pm on May 14th, 2012 Permalink | Reply

      In Firefox and IE9, site title is way too large for sr_RS.

      I suggest that link to wp.org also be i18n so that we can link back to locale sites.

      • Andrew Nacin 6:39 pm on May 14th, 2012 Permalink | Reply

        Yeah, okay, something weird with Typekit. I noticed it as well. We will get that fixed.

        The link to wp.org was an oversight. It is now translated and it was already in the POT file, so, all set.

    • Kenan Dervišević 7:02 pm on May 14th, 2012 Permalink | Reply

      @nacin Could you redeploy bs_BA? I fixed a few typos. Thanks :)

    • Naoko 3:32 am on May 15th, 2012 Permalink | Reply

      @nacin I noticed a couple of things out of context. Could you redeploy JA?
      Language detection is working beautifully.

      • Andrew Nacin 4:37 am on May 15th, 2012 Permalink | Reply

        Done! Good to hear.

        • Naoko 4:45 am on May 15th, 2012 Permalink | Reply

          Thanks! Noticed that the facebook share button is giving me an error & Safari like button is missing.

          30A830E930FC

          (Please click the image for a larger screenshot)

          • Andrew Nacin 4:57 am on May 15th, 2012 Permalink | Reply

            I check every few months, but there is still no official Facebook page for Safari.

            I will ask @otto42 for some help with the Facebook error, thanks!

    • anotherkaz 3:04 pm on May 15th, 2012 Permalink | Reply

      Thai is ready

    • littlebouddha 10:11 am on May 17th, 2012 Permalink | Reply

      Ready for approval for the French version, Xavier you’re in charge also ? If not how to become on ?

    • terkel 3:18 am on May 19th, 2012 Permalink | Reply

      Hi!
      “Visit website for more info” for Internet Explorer is linked to http://www.microsoft.com/windows/internet-explorer/ but this is automatically redirected to the US page.
      http://windows.microsoft.com/ie works better since this is locale-aware.

    • Takeru Suzuki 5:40 am on May 19th, 2012 Permalink | Reply

      Thanks for your quick response! I love this project :-)

    • DjZoNe 9:50 am on May 21st, 2012 Permalink | Reply

      Please deploy the hungarian translation as well ;)

    • drssay 8:20 am on May 27th, 2012 Permalink | Reply

      Korean is done. Please, deploy.

  • Andrew Nacin 2:55 pm on April 20th, 2012 Permalink | Reply
    Tags: , ,   

    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 20th, 2012 Permalink | Reply

      Thanks for the heads up.

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

      Done.
      Thanks.

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

      ta_LK has been released.

      We also used tags to build it.

    • Mark Thomas Gazel 9:03 pm on April 22nd, 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 27th, 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 6:33 pm on April 9th, 2012 Permalink | Reply
    Tags:   

    Cross-posting from the GlotPress development blog: Hello, and a call for comments/feedback.

     

  • Andrew Nacin 9:16 pm on April 5th, 2012 Permalink | Reply
    Tags:   

    I added persistent caching to translate.wordpress.org, fixed a bug in GlotPress, and tweaked a few things. The result: GlotPress is now super fast. Even the really slow project pages now load in an instant. See for yourself: http://translate.wordpress.org/projects/wp/dev. Let me know if you see anything funky, such as stuck values (caching issues) etc.

     

    • Zé 9:28 pm on April 5th, 2012 Permalink | Reply

      8O

    • Mattias Tengblad 10:41 pm on April 5th, 2012 Permalink | Reply

      Nice! Good work :)

    • Carlos E. G. Barbosa 12:22 am on April 6th, 2012 Permalink | Reply

      Great! Thank you!

    • Wacław J. 10:53 am on April 6th, 2012 Permalink | Reply

      What does persistent caching mean?

      • Andrew Nacin 12:50 pm on April 6th, 2012 Permalink | Reply

        In this case, it means that we’re now caching data in memcached, a persistent data store. So we query something expensive on one pageload, store it in cache, and pull it from memcached (rather than the database) until that cache gets cleared. Going to memcached is often going to be quicker than the DB, especially for expensive (or high numbers of) queries. A particular cache then gets cleared when the data changes (a count of translated strings gets reset when a string is translated, etc). All you really need to know, though, is that it is awesome. :-)

  • Andrew Nacin 5:02 pm on April 4th, 2012 Permalink | Reply
    Tags: , ,   

    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 4th, 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 4th, 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 4th, 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 9th, 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 5th, 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 5th, 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 5th, 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 5th, 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 5th, 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 5th, 2012 Permalink | Reply

              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 5th, 2012 Permalink | Reply

    • Akerbeltz 10:11 am on April 5th, 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 11th, 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 11th, 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 12th, 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.

  • Andrew Nacin 9:12 pm on March 2nd, 2012 Permalink | Reply
    Tags: , , , , ,   

    Request for feedback from East Asian languages for WordPress 3.4 core modifications.

    In #8759, I’m looking for feedback for the editor word counts.

    In #16079, I’m looking for feedback for the length of auto-generated excerpts.

    If you could test the code and post in the relevant tickets, it would be much appreciated.

     

  • Andrew Nacin 9:55 pm on February 7th, 2012 Permalink | Reply
    Tags:   

    Need some RTL feedback here: http://core.trac.wordpress.org/ticket/6425. How should be be handling RTL content in RSS feeds?

     

    • geminorum 1:02 am on February 8th, 2012 Permalink | Reply

      I think there is no need to add direction styles on the feed content. The readers usually support the RTL automatically, such as Google Reader and IE feed reader. Also, we’re usually apply the styles when fetching via code into the content, that is also RTL.
      The advantage is only for when mixing RTL and non-RTL feeds together.

  • Andrew Nacin 9:52 pm on February 7th, 2012 Permalink | Reply
    Tags: , ,   

    I’ve updated the list of 3.4 changes:

    • New: Localizing commas, as a tag separator
    • New: Fields that should always be LTR
    • New: Spellchecker language is now translatable
    • Changed: How precisely core detects that a language is RTL (it now uses a translated string)
     

  • Andrew Nacin 2:50 pm on January 31st, 2012 Permalink | Reply
    Tags: , ,   

    3.4 update: Localizing quotes and apostrophes that go through wptexturize(). More

     

    • Xavier 12:25 am on February 8th, 2012 Permalink | Reply

      It seems the right place and time to comment about curly quotes.

      I made a quick update to my trunk install’s MO files, just enough to be able to check my curly quote break post. Still no cigar.

      This has long been a personal quest for me (I wrote some tests at the time), and has been pushed over and over, through many tickets with varying degrees of relevancy to the issue (AFAICT). Since there’s a lot of effort on i18n during this cycle, I would love it 3.4 could put an end to that issue.

      I can open a brand new ticket if need be.

      • Andrew Nacin 12:57 am on February 8th, 2012 Permalink | Reply

        The bugs there are not i18n-related. They were nearly fixed in #4539 (for which the other ticket was closed as a duplicate), but the tests were not comprehensive enough and quite a few things broke, so it was backed out of trunk.

        So, no new ticket needed. Just look at #4539 and see if there is anything that can be done.

  • Andrew Nacin 9:27 pm on January 29th, 2012 Permalink | Reply
    Tags: ,   

    In 3.4, you no longer need any PHP to customize the defaults for start of week, feed language, or default timezone. (You would have hooked into populate_options for these.)

    start_of_week and timezone_string/gmt_offset are now translatable, and rss_language is gone (it uses the site’s locale, now).

    I’ve created a page here that outlines all changes to 3.4 so far, including the details for how to set these defaults: Important Changes for WordPress 3.4. I will update it as more changes happen.

     

  • Andrew Nacin 5:19 am on January 29th, 2012 Permalink | Reply
    Tags: ,   

    For 3.4, the default links are now translatable, both titles and URLs. http://core.trac.wordpress.org/changeset/19781

    I left out the URLs for extend/plugins/, themes/, and ideas/ from being translated as there are not yet official localized resources for these, and I would not want to send them off-site. Since the forums are a better conduit for feedback anyway, I demoted Suggest Ideas down the list, moving the Support Forums up one.

     

  • Andrew Nacin 8:48 pm on January 27th, 2012 Permalink | Reply
    Tags: ,   

    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 6:55 pm on January 27th, 2012 Permalink | Reply
    Tags: ,   

    In 3.4, you will no longer need to specify a $wp_default_secret_key, in $locale.php or in default-constants.php. For many of you, this means your $locale.php file will now be empty. Branch off 3.3 and remove $locale.php from /trunk/dist/ if that is the case. See ticket 19599 for more.

     

  • Andrew Nacin 8:38 pm on January 26th, 2012 Permalink | Reply
    Tags: ,   

    All locales: In 3.4, you will no longer need to override wp-admin/setup-config.php. The strings in this file will now be included in the POT, and the config file will be generated properly regardless of the wp-config-sample.php placeholders such as “your_username_here”. See [19760] and #18180.

     

  • Andrew Nacin 10:46 pm on January 25th, 2012 Permalink | Reply
    Tags: , , , , dv, , , ha, , ps, , , uz_UZ, yi   

    RTL locales: In 3.4, you will no longer need to specify $text_direction = 'rtl'; in your $locale.php file. Please remove it from $locale.php, and if this makes your $locale.php empty, then remove the file. (Please branch /trunk/ off into /3.3/ first, in case there is a 3.3.2.)

    The following locales have been included: ar, ckb, fa_IR, he_IL, ug_CN, dv, fa_AF, ha, ps, uz_UZ, yi. If you are missing (or are incorrectly included), let me know.

     

← Older posts

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
Follow

Get every new post delivered to your Inbox.

Join 120 other followers