WordPress.org

Translate WordPress

Tagged: announcement Toggle Comment Threads | Keyboard Shortcuts

  • Sergey Biryukov 2:31 am on March 20, 2015 Permalink |
    SergeyBiryukov • ru.wordpress.org editor
    Tags: 4.2, announcement, ,   

    Font family for headings in RTL locales changed to Arial 

    A quick note, we’ve switched the font family for headings in all RTL locales to bold Arial, see ticket #30807. The change only affects the admin area.

    If that affects your locale and you have any concerns regarding this change, please comment on the ticket. Thanks!

     
  • Dominik Schilling (ocean90) 10:24 pm on March 19, 2015 Permalink |
    ocean90 • de.wordpress.org editor
    Tags: announcement   

    Per-project permissions for Translation Editors (previously Validators) 

    Author shouldn’t show as validators or be able to validate strings – Meta Ticket 741

    I’m happy to announce that we finally have a more granular system to manange permissions for translate.wordpress.org. 🎉🎊

    Previously anyone with the role of Validator, Contributor, Author or Editor had the ability to validate strings for a language. Now we have a new role Translation Editors. The role is a complementary role and can be assigned to editors, authors, contributors or subscribers.
    The Users list table has a new column which will display all roles of a user.

    user-roles

    Only users with the Translation Editors have the the ability to validate and approve strings. To promote a user to a translation editor you can use the action link in the Users list table (see screenshot above) or use the new page Users > Translation Editors.

    The page is similar to the Users list table but lists only translation editors.

    translation-editors

    Here you can also add new translation editors. This form allows you to specify for which projects the editor should get access. With All Projects selected, the translation editor will have validation permissions for all projects, including newly-added projects.

    If you select Custom you will be redirected to an Edit Translation Editor screen.

    edit-translation-editors

    Here you can select one or more projects. The list includes all 12 “master projects”. The editor will have access to all sub projects and newly-added sub projects of a selected “master project”.

    With this update badges for translation editors are now automated too. ~300 users have already a new badge! 💥
    (Badges are visible at profiles.wordpress.org/yourname)

    The migration process has moved all validators to the new Translation Editor role, same for editors. Users with the Validator role now have the Subscriber role. All translation editors were whitelisted for all projects, which can be changed as needed. Contributors and authors are untouched. Each team should do a case-by-case review if a contributor/author should be able to approve strings.

    I hope you enjoy the update as much as I do. 😀
    If you have any questions feel free to use the comments or ping @ocean90 on Slack.

    (Badges for translation contributors will come soon.)

     
  • Japh 4:00 am on March 12, 2015 Permalink |
    japh • en-au.wordpress.org editor
    Tags: announcement   

    Polyglots Asia/Pacific Meeting Time Change Announcement 

    Hello Polyglots in the Asia/Pacific region!

    We’ve found that the current meeting time isn’t working very well. Only a handful of people, at best, seem to be able to attend. So we’re moving the time back 2 hours, which seems like a better fit.

    The new time is 04:00 UTC on Thursday, every week. So next week’s meeting will be at 2015-03-19T04:00:00+00:00. (This makes it within daylight hours for the vast majority of those affected.)

    If you have legitimate concerns about the new time, please comment on this post so we can all discuss it.

    Hopefully this works better for everyone!

     
  • Dominik Schilling (ocean90) 10:09 am on February 25, 2015 Permalink |
    ocean90 • de.wordpress.org editor
    Tags: announcement, slack   

    Slack: Introducing WordPress Translate bot 

    If you haven’t heard of Slack yet you should go ahead and join the WordPress team on Slack and then look for the #Polyglots channel.

    The #Polyglots channel on Slack is where we have our weekly chats and where you can ask questions and look for help with translations. To log into Slack, all you need is your WordPress.org username and to follow the instructions here: Chat.WordPress.org

    If you are a Translation Editor (validator) for a locale, it is highly recommended that you join the channel.

    New: WordPress Translate bot

    The slack channel now has a bot “WordPress Translate” which informs about auto-generated release packages and language packs:

    A new language pack was built.

    A new language pack was built.

    A new release package was built.

    A new release package was built.

    And the bot will send notifications if new strings are available for translation:

    New strings were imported to translate.wordpress.org

    New strings were imported to translate.wordpress.org

     
  • Andrew Nacin 8:50 pm on February 24, 2015 Permalink |
    nacin
    Tags: announcement   

    Thought it might be fitting to post this as today marks five years since @ocean90‘s first patch to WordPress. As has been obvious to some of you, I have stepped back from i18n in the past few months, especially after 4.1’s release and as WordCamp Europe, WordCamp SF, the community summit, and Slack have empowered so many of you. I am stretched across a lot of projects, and Dominik very willingly stepped up to take on a lot of responsibility for improving Rosetta, core language packs, and related projects. He’s a highly respected WP core developer, he’s previously helped me on a number of i18n projects, and he’s slid into this role with ease. It’s also time for the technical point of contact to be a polyglot again. :-)

    @stephdau has also been instrumental for the massive project to translate plugins and themes (including language packs, localized plugin/theme directories, and the like). Also, you may have noticed a lot of coordination across these initiatives now happens in a #meta-i18n channel on Slack.

    While I haven’t gone anywhere and I’m still helping a bit behind the scenes, please consider @ocean90 the new @nacin and the primary point of contact core/dotorg i18n and the like!

     
  • Dominik Schilling (ocean90) 10:49 am on February 18, 2015 Permalink |
    ocean90 • de.wordpress.org editor
    Tags: , announcement   

    Prepare your locale for 4.1.1 – Update: WordPress 4.1.1 has been released 

    Edit: WordPress 4.1.1 has been released. Packages are currently build every hour 6 hours.

    WordPress 4.1.1 will be released in the next 24 hours. In order to benefit from the automated release process it could be possible that you have to prepare your locale first.

    Translations must be at 100%

    (This includes wp/dev, wp/dev/admin and wp/dev/admin/network.)
    Currently 39 locales are at 100%, 10 locales are at 99%. Most of them don’t have translated the two new strings in 4.1.1, see String changes in WordPress 4.1.1. Please check also for existing waiting strings and clear them out, otherwise the build will be skipped.
    (Also do not forget about the default themes and Akismet project.)

    Update version in readme.html

    (For these locales: ar, bs_BA, cy, de_DE, de_CH, en_CA, eo, es_PE, eu, fi, fr_FR, he_IL, it_IT, nb_NO, pt_BR, pt_PT, ro_RO, sv_SE, th, and tr_TR.)

    • If you have custom changes on i18n.svn.wordpress.org and you are using branches/4.1 to release your package you only have to change the version in readme.html.
    • If you’re using tags/4.1 you have to create a new tag for 4.1.1 first. It’s just a copy of trunk/ or tags/4.1 and the version change to readme.html.
    • If you have tags/4.1 and branches/4.1, but no tags/4.1.1 the build will use branches/4.1.

    If you have any questions just comment here or ping me @ocean90 on Slack #polyglots.

     
  • Dominik Schilling (ocean90) 6:12 pm on January 17, 2015 Permalink |
    ocean90 • de.wordpress.org editor
    Tags: , announcement   

    String changes in WordPress 4.1.1 

    The upcoming minor release (no date yet) will include two new strings. You can see them in the wp/dev project.

    We’ve added a missing context to “Previous” and “Next” which are both used for the post navigation. The change will prevent a clash with the “Next” (with meaning “Continue”) string used during installation. Thanks @pavelevap for spotting this out. The related changeset is [31082].

    In the past, minor releases had no string changes, but now we have the automated release process and language packs and want to give this a try.

    19 locales are already at 100% (nice!), 32 have two untranslated strings. Let’s fix this! :-)

     
  • Andrew Nacin 12:25 pm on December 18, 2014 Permalink |
    nacin
    Tags: , announcement,   

    WordPress 4.1 instruction manual

    Hello polyglots! In the next 3 hours or so, @johnbillion will be starting the release process (in #core in Slack). Please make sure you are 100% translated for WordPress 4.1 and all subprojects, and also do not forget about the Akismet project.

    I’d expect a release somewhere around 1600 UTC, but for most locales, the release process is now automated. Please read on.

    Part 1, Language Packs

    If you are 100% translated at the time of 4.1’s release, a language pack will be generated for you. This is a ZIP file consisting of PO and MO files only, and is used for the language chooser during the install process, and for the language switcher on the settings screen.

    If you become 100% translated some time after 4.1’s release, a language pack will be generated for you once the script is run. This will be around every hour.

    If you are 100% translated, a language pack has been created, and then you modify a translation to fix a typo or whatever, a language pack will be regenerated for you once the script is run. Please do not do this with unnecessary frequency, as it triggers an update across all WordPress sites.

    Part 2, Release Packages — IMPORTANT CHANGES AHEAD

    release package is what you’re used to building using the form on Rosetta’s dashboard. This is a ZIP file consisting of WordPress in its entirety, along with PO and MO files for core, the PO and MO files of default themes and Akismet, and any custom changes you have.

    Do you have custom changes? For the purposes of this exercise, your locale falls under one of these four groups:

    • You have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale.
    • You have no custom changes for 4.1.
    • You have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php.
    • You have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications.

    Here are the details on each:

    • If you have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale, you do not need to do anything. Your release package will be created automatically for you. An example locale is en_GB.
    • If you have no custom changes for 4.1, please ensure you have an empty branches/4.1/dist or tags/4.1/dist directory at i18n.svn.wordpress.org. (Having an empty trunk/dist directory does not help you.) You do not need a dist directory if branches/4.1 or tags/4.1 is empty. An example would be nl_NLYour release package will be created automatically for you.
    • If you have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php, please ensure these files exist in a branches/4.1/dist or tags/4.1/dist directory at i18n.svn.wordpress.org. (Having your stuff in only trunk/dist does not count.) An example would be eo or fr_FRYour release package will be created automatically for you.
    • If you have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications, you will need to create a package via Rosetta as you have done in the past. For this, We are phasing out the ability to ship any customizations beyond license, readme, and wp-sample-config.php. This means you need to reach out to the WordPress core contributors to fold your modifications into WordPress core. You can start this process by creating a Trac ticket.

    To summarize:

    • If all you have is a license, readme, and wp-config-sample.php (or no custom changes at all), everything will be automated for you for WordPress 4.1 if you follow the instructions above. Both language packs and release packages will automatically be created once 4.1 is announced. If you are not at 100% at that time, then language packs and release packages will be created when you reach 100%. If you are later modify a translation (to fix a typo, for example), your language pack and release package will be regenerated.
    • If you have extensive custom changes, you will need to manually create a package via Rosetta as you have done in the past. This option is being phased out in 2015.

     

    If you go to the releases screen on your Rosetta dashboard, you’ll see a new notice that explains what the system thinks your status is. If you have any questions, comments, concerns, or issues, please comment here or find me or @ocean90 in #polyglots on Slack.

    If your locale is currently eligible for automatic creation of release packages (which includes being at 100%), you’ll find an RC3 build generated from tags/4.1-RC3 waiting for you on your dashboard. Please inspect these ZIPs. Those locales are: az, bs_BA, de_DE, en_CA, en_GB, eo, fi, fr_FR, it_IT, nb_NO, nl_NL, pt_PT, ro_RO, and sv_SE (zip links).

     
  • Ze Fontainhas 9:39 pm on September 25, 2014 Permalink |
    vanillalounge • pt.wordpress.org editor
    Tags: announcement   

    Since many of you will be at WordCamp Europe this week-end, and may notice my absence, I suppose that this is as good a moment as any to announce that I am stepping down as the “lead” (never too sure what to call it) of the Polyglots’ team.

    It has been a fantastic run of more than 5 years, and I am not leaving in anger or anything like it; instead, as it so often happens, a combination of reasons from both my personal as well as my professional life dictate that I must step back, for an indeterminate amount of time (this decision affects not only Polyglots, but also my presence as WordCamp organizer, including Europe 2014, and forums’ volunteer, among others, by the way).

    I have discussed this with both @samuelsidler and @nacin, and we are working on a smooth transition plan, which means that I’ll probably be dealing with operational issues for just a bit longer, but I expect that Sofia will be the perfect occasion to kick off the debate on that (just make sure to report back here).

    Also, you won’t be completely rid of me: I am not moving to the Galapagos :) and will probably hang around as one of the translators of pt_PT: as usual, feel free to ping me at any time, about whatever, whenever you need to, keeping in mind that, from now on, I will only have opinions to offer, not solutions.

    In closing, I’d just like to add that I have made many great and (I hope) lasting friendships here, which I fully intend to keep and that I will remember my days here, with all of you, with fondness and gratitude.

    Thank you and happy translating :)

     
  • Andrew Nacin 4:19 pm on September 4, 2014 Permalink |
    nacin
    Tags: , announcement, ,   

    Instructions for 4.0, which will be released in the next 15-30 minutes:

    • The need to create a localized build through the Rosetta form is unchanged for 4.0. This will go away very soon, but we couldn’t get all the ducks in a row to make this go away for 4.0. I’m trying for 4.0.1. Thank you so much for your patience as we work to make the experience painless for all of you.
    • As usual, you will build your release off the 4.0 tag, which will exist soon. Since you’re building off of 4.0, you don’t need the revision number (HEAD is fine), but it’s 29485.
    • CHECK YOUR BUILD FIRST. Especially $wp_version in wp-includes/version.php.
    • If you have WPLANG defined in wp-config-sample.php, the build will be rejected. If you don’t translate this file and this file is thus an exact copy of the core file, you may delete it. Only mess with trunk / 4.0, not dist directories from 3.9 or earlier.
    • Thanks to your feedback, the language chooser will not show for a localized build. For the regular build, it will show. These languages are via the API at https://api.wordpress.org/translations/core/1.0/?version=4.0 and reflect any translations that are 100% for all three projects (wp/dev, wp/dev/admin, wp/dev/admin/network). Percent completion is checked periodically and language packs are then built.
    • (This is mainly for @pavelevap…) If you are not at 100% for all three projects, you may ask for me to manually trigger an incomplete language pack, for the purposes of being available in the language chooser. I’d rather not, though — this is API-driven and we can always get the language in there once you finish your translation.
    • Do not forget to 100% translate Akismet. There were no string changes in the default themes.

    If you have any questions, please leave a comment, and @ocean90 or I will address them. If there is an urgent issue, please ping me in #wordpress-polyglots or #wordpress-dev.

     
  • Andrew Nacin 11:34 pm on September 3, 2014 Permalink |
    nacin
    Tags: , announcement,   

    You have about 14 hours to complete your translations for WordPress 4.0.

    I’ve added one last string, “Release Lead,” for use on the credits page. If you were at 100% for 4.0, don’t worry, you have a language pack built already, but it’d be nice if you could translate this.

    Please ensure you are 100% for wp/dev, wp/dev/admin, and wp/dev/admin/network. Currently 19 languages have done this (minus the new string).

    pl_PL, he_IL, my_MM, and eu (Basque) are all at 100% for wp/dev but are not at 100% for the administration projects. Another 30 languages are at 90% or higher for wp/dev — so close!

    WPLANG should be removed from wp-config-sample.php. If you have a custom wp-config-sample.php file in your SVN trunk/dist directory, please update it. See how German did it here.

    If you are translating via SVN please make sure you are importing each of your PO files into translate.wordpress.org, for language packs.

    More launch day instructions to follow. Thanks for your patience. If you have any specific questions you’d like me to answer, please include them below so I can be sure to cover them in my instructions.

     
  • Andrew Nacin 4:00 am on August 14, 2014 Permalink |
    nacin
    Tags: , announcement,   

    I’ve finally fixed a very broken translate.wordpress.org and pushed 4.0 to https://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 |
    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 |
    nacin
    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!

      but..
      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!”

      Sweet!

    • 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 |
    nacin
    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!

     
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