WordPress.org

Ready to get started?Download WordPress

Translate WordPress

Updates from April, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Birgit Olzem 6:57 pm on June 18, 2014 Permalink | Log in to leave a Comment
    CoachBirgit • de.wordpress.org editor
    Tags: international sites, o2, , team blog   

    At our first Contributor Day, at WordCamp Hamburg last monday, we have build a team to improve our germanophon community. In this procedere we´ve discussed how we can organize our team.

    One idea is to having an own P2 / O2 Make (public reading), where we can talk in german without flooding the existing make blogs here at w.org. Temporary we try to organize with a trello board. For small tasks it is a fine solution, but for general discussions to confusing.

    Here are some scenarios, that we had extracted:

    • XX.wordpress.org/make
    • make.wordpress.org/XX
    • make.wordpress.org/polyglots/XX
    • make.wordpress.org/community/XX

    What do you think? Is this an idea, you can deal with and use for your community?

    How is your workflow in your community?

    Thanks for your opinion and engagement to make the world a little better ;-)

     
    • daveshine (David Decker) 7:13 pm on June 18, 2014 Permalink | Log in to Reply

      For “speaking URLs” I like “make.wordpress.org/XX” the best, otherwise also “XX.wordpress.org/make” makes sense. The other 2 are already too long in my opinion.

    • Ze Fontainhas 9:20 pm on June 18, 2014 Permalink | Log in to Reply

      xx.wordpress.org/something is what makes sense to me, in which “something” could be either “team”, “discuss” or any variation of that. “make” already has a specific connotation I guess

    • Andrew Nacin 11:19 pm on June 18, 2014 Permalink | Log in to Reply

      I definitely think we can do something on xx.wordpress.org (something I remember discussing previously).

      Alternatively: Let’s say your forums were bbPress 2.0 and everyone had them — would a single “meta” forum area be appropriate and sufficient?

      • Birgit Olzem 10:41 am on June 19, 2014 Permalink | Log in to Reply

        Yes, we´ve talked about this topic at Contributor Day in London last year.

        I think forums are not the best solution. For beeing consistently in organisation and communication for teams, I think we must use the infrastructure P2 / O2 Make-Blogs. New members could better get envolved with this scheme / model. They could orient oneself and easily find the way to communicate and contribute to.

        My thought goes a little bit forward: The user management for access the teams can driven by rosetta sites admins / editor resp. the locale reps. Every user with a .org profile could sign up over contact form.

        The main argument, why I think P2 / O2 is the best way: Notifications. It is much easier to get notified over a make blog, instead a topic in forums. And we can inform better about getting envolved with notes in sidebar and so on.

        All the arguments, why we use – for example – here for polyglots the same way to communicate with each other.

      • Ze Fontainhas 12:07 pm on June 19, 2014 Permalink | Log in to Reply

        Agree with P2/O2 being better than forums, for all the reasons listed by Birgit and David. That said, let’s keep in mind that make/polyglots is the home of translators and not necessarily a country/locale community. Granted, they often overlap, but not always. Speaking exclusively for pt_PT, we’d have no problem moving all discussions about translations to a .org hosted P2/O2, but would have a serious one moving the community debate there; community management requires a lot more than just slapping a P2/O2 on it, and neither does that discussion necessarily belong exclusively on make/polyglots, nor is it mature enough (yet) to implement. Baby steps.

        • Remkus de Vries 12:30 pm on June 19, 2014 Permalink | Log in to Reply

          Agreed 100%.

        • daveshine (David Decker) 1:24 pm on June 19, 2014 Permalink | Log in to Reply

          As of my understanding it’s not about touching the Polyglots base here, it’s just offering the P2/O2 functionality to locale/country communities to power their blogs. Example: de.wordpress.org/blog/ would open as a P2/O2 — that would be awesome!

          This P2 here has to stay, absolutely!

          • Birgit Olzem 1:39 pm on June 19, 2014 Permalink | Log in to Reply

            Sorry for objection @daveshine, don´t replace the standard blog for P2/O2!

            The blog is reserved for announcements and public articles. Not for discussion about organisation and improvements for locale communities.

            I prefer de.wordpress.org/make

            It´s a better consistence and namespacing

            „make“ in context doing great stuff for / with / in the locale community

            Organising contribution to other w.org projects für beginners in native language and so on.

          • Ze Fontainhas 1:43 pm on June 19, 2014 Permalink | Log in to Reply

            That was my point: community-operation-under-org is not defined or discussed, at this point (and keep in mind that “locale” isn’t necessarily “community”, see Belgium, Switzerland (1 community, n languages), or French (1 language, n communities). I am all for discussing it, but just not in this specific context, which has a clear, feasible and objective scope.

        • Torsten Landsiedel 7:44 am on June 20, 2014 Permalink | Log in to Reply

          This is not about having central place to discuss all things community, it is about adopting the idea of the make-blogs to locales. (At least for me.)

          Examples:
          de.wordpress.org/translation -> discussions about German translations
          de.wordpress.org/supporting -> discussions about supporting in the German forums
          de.wordpress.org/core -> discussions about German/translation related core patches
          etc. etc.

          This could be a place to prepare contributions in German and to discuss things which don’t have to flood international P2s.

          We don’t want to use the name “make” or make the make-blogs obsolete. It is just a step between, like we do now (with a wp.com blog) with translation here: http://teamwpde.wordpress.com/

          Or would this be an act of isolation again?

          • Ze Fontainhas 9:35 am on June 20, 2014 Permalink | Log in to Reply

            That looks like a lot of buckets :) It seems to me that discussing things like support and core patches, even if specific to a locale, could benefit all locales by being at the same place and in English, no? This may require some @samuelsidler input, so ping.

            • samuelsidler 4:21 am on July 9, 2014 Permalink

              Yeah, too many buckets. In general those things belong back on the English-speaking sites. Only locale-specific things should be on the locale sites.

          • Birgit Olzem 11:11 am on June 20, 2014 Permalink | Log in to Reply

            @zodiac1978: I think, it don´t need more than one P2. The locale specific topics – in native language for german speaking – could separated with categories and colour tags.

            The big picture, why I want to discuss it here, is to make this native speaking P2s available for all people, who has a w.org login.

            I´ve talked with @samuelsidler some days ago and he meant, that we could use our community site wpde.org for this case.

            But I think, that option is likely an isolated application. We´re endeavored to desestablish this gap.

            @vanillalounge you´ve criticized this same gap in your keynote at #wchh14

            Please correct me, if my thoughts going into a wrong direction.

            I seem to remember, that at #wceu last year it was a topic, to bring the communities together. So I think, using the w.org infrastructure is the best way – because we all use the same CI / CD for the project.

            For us in Germany it is one mouseclick away to setup an own P2, but is this the best way for working together as a big worldwide community?

            The second argument. If we set up an own P2, so who is the Gatekeeper? If we use w.org infrastructure, so there can the respective user for the international sites step into this role, too. It is easier to maintain and respects the trademark policies.

            My 2cts and reflects my personal opinion. ;-)

    • obstschale 10:31 am on June 19, 2014 Permalink | Log in to Reply

      I like xx.wordpress.org/sth. Ze’s arguments are good.

    • daveshine (David Decker) 11:07 am on June 19, 2014 Permalink | Log in to Reply

      I vote for a P2/O2 solution! It’s more native and dynamic and most “insiders” are already used to it because of the Make network on .org.

      Especially easy live comments, feeds and subscriptions make it more easy, and if there’s something more “long form” content to tell about, than the blog functionaly is also an advantage.

      Thanks, Dave :)

    • Caspar 2:41 pm on June 20, 2014 Permalink | Log in to Reply

      @nacin Only because our Trello boards are flooded and we *really* need to create a solution within a matter of days rather than weeks:

      Would xx.wordpress.org/sth be available very soon? Or would it need to be discussed in general?

      We generally wouldn’t have a problem to use a self-hosted P2 for now if it wasn’t for the idea being so overwhelmingly intriguing that people logging into their w.org profiles could just post away in a xx.wordpress.org/sth solution.

      So, is it something we could help making available real soon? Or should we go with a self-hosted for now?

    • Caspar 2:42 pm on June 20, 2014 Permalink | Log in to Reply

      community management requires a lot more than just slapping a P2/O2 on it

      Got that. :)

  • Naoko Takano 2:25 am on June 2, 2014 Permalink | Log in to leave a Comment
    Nao • ja.wordpress.org editor
    Tags: ,   

    Our forum volunteers noticed that the “hot topic” section of the Japanese forum top page is now filled with spammy tags.

    From bb-admin, I can see a bunch of posts from bozo users with such tags. The posts themselves are no longer appearing, but looks like the hot topic section is ignoring the bozo status.

    The same issue with other local forums, e.g. http://de.forums.wordpress.org and http://nl.forums.wordpress.org

     
  • Samuel Sidler 12:15 pm on May 25, 2014 Permalink | Log in to leave a Comment
    samuelsidler  

    There’s been a lot of things happening recently. Here’s a quick recap:

    Your feedback on all of these posts is incredibly important. If you have thoughts on any of these topics, leave it on the respective post. Thanks for reading!

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

    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.

  • Samuel Sidler 4:08 pm on May 21, 2014 Permalink | Log in to leave a Comment
    samuelsidler  

    Howdy Polyglots!

    Over time, translation teams come and go, but until now, we’ve kept those translations publicly available and linked to regardless of how old they get.

    As an example, I’m currently in Malaysia and get recommended the Malay (Bahasa Melayu) localization. However, that localization hasn’t been updated since 2.9.2! @markoheijnen‘s plugin details where various localizations stand.

    This situation isn’t ideal because we don’t want to offer old versions of WordPress as they’re often insecure.

    Going forward, I’d like to propose we do the following:

    • Only offer “major version” and “major version minus one” for download on Rosetta sites. Currently, this would be WordPress 3.9.x and 3.8.x.
    • Localizations that have only shipped prior versions of WordPress would be considered “inactive.” (e.g., 3.7.x and before)
    • Inactive translations would get their download button removed on their Rosetta site.
    • Inactive translations would get a bar across the top of their Rosetta site (on all pages) that says, in English: This translation of WordPress is currently inactive. If you’re interested in translating WordPress to <locale>, join the Polyglots team and find out how. Download the English (US) version instead.
    • All other pages on the Rosetta sites would remain active, including the Releases page, which lists old versions for download.

    The proposed text could be changed/improved, of course. How does that sound to everyone?

     
    • Gabriel Reguly 7:58 pm on May 21, 2014 Permalink | Log in to Reply

      Hi,

      I could not find @markoheijnen‘s plugin, so I am posting it here :-)

      Our pt-BR/pt-br is located ar http://br.wordpress.org and we are up-to-date with 3.9.1

      Cheers,
      Gabriel

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

      Sounds like a plan to me assuming the “Join the Polglots team” would actually link to the particular translation team for that locale

      • samuelsidler 3:16 pm on May 22, 2014 Permalink | Log in to Reply

        It wouldn’t, actually. Because there’s a good chance there isn’t a team to join. We’d want to link them to make/polyglots and they can use the blue welcome box at the top to get started. From there, the queues in the handbook should get them directed to the right team.

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

          I would think there’d cases where there was a team but it lacked momentum. Wouldn’t you be bypassing those?

          • samuelsidler 8:01 am on May 23, 2014 Permalink | Log in to Reply

            Not necessarily. We can update the blue notice here to get people to look at the list of translation teams, which will be in the handbook in the not-too-distant future.

    • Torsten Landsiedel 10:59 am on May 22, 2014 Permalink | Log in to Reply

      Sounds great!

    • Stephen Edgar 2:43 am on May 23, 2014 Permalink | Log in to Reply

      Looks reasonable, with one exception, only offer the current “major version” via the ‘download’ button, currently, this would be WordPress 3.9.x.

      Reason being is I’d suggest we do not encourage to download and install 3.8.x (at the time of writing this), one of the first things you would see after installing 3.8.x is a notice that 3.9.x is available, though only in en_US and not the locale of your choice that you just installed, not the best user experience IMHO.

      If you are explicitly looking for a major versions previous release then head over to the release archive and go for it.

      • samuelsidler 8:30 am on May 23, 2014 Permalink | Log in to Reply

        I talked it over with Remkus just now to make sure I understood your point and I have a few thoughts.

        • I’m okay with offering users 3.8.x (as of now) when 3.9.x is out. I think offering them a supported version of WordPress is good enough and better than what we’re doing now.
        • Some users may choose to upgrade from 3.8.x to 3.9.x on install. They’ll use 3.8.x language files. There’s (currently) no other way for them to download 3.9.x with 3.8.x language files.
        • Some users may choose *not* to upgrade from 3.8.x to 3.9.x. I think this is fine too because 3.8.x is supported.
        • In the future (see @nacin‘s post above), we may have automatically-built packages of e.g. 4.1.x with 4.0.x language files. Then we could always offer the latest version (4.1.x in that example) and some things will just be in English. Localizations could update their language packs over time.

        tl;dr: I think it’s fine to offer 3.8.x on download in the interim. The user experience is no worse than it is now and we’re still putting them on a supported version of WordPress.

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

          I’m assuming it’s not going to be that difficult to automatically import the 4.0.x translations into the 4.1.x translations project in GlotPress and use that to actually build it.

          • Stephen Edgar 8:59 am on May 23, 2014 Permalink | Log in to Reply

            Yep, I’m fine with all of that and seems reasonable.

            When Nacin has created a new tag in Glotpress this AFAIK includes copying the existing strings from the old tag to the new tag so indeed (in this case) quite a few, the majority even, strings are copied. It won’t be 100%, but will be 100% less the major versions new string changes.

            Extending that idea more towards your comment Remkus, maybe not having versions in GlotPress is a way forward for example if `post` has been translated by the localisation team it is able to be used by any version that needs `post` translated. Further, remove the projects and `post` becomes available to any plugin or theme for that locale, in it’s simplest form that could work but context for more complex strings not so much.

    • yt09 6:39 am on May 24, 2014 Permalink | Log in to Reply

      I’m not part of the team, but I noticed that http://wpcentral.io/internationalization/ is missing information on Chinese (Taiwan). The website is http://tw.wordpress.org/ and the native name is 正體中文. The most recent version is 3.9.1. I’m contacting them since I noticed they are not listed at http://codex.wordpress.org/L10n:Localization_Teams

    • samuelsidler 12:08 pm on May 25, 2014 Permalink | Log in to Reply

      I filed meta ticket #487 on this.

  • Stephen Edgar 3:57 am on May 21, 2014 Permalink | Log in to leave a Comment
    netweb • en-au.wordpress.org editor
    Tags: ,   

    Please verify the WordPress version before releasing localized versions.

    For WordPress 3.9 and 3.9.1 a handful of localized builds were compiled against an incorrect tag/head/revision and released, the effect of this is, in this case resulted in end users WordPress installs would now display that they are now running `4.0-alpha`. There is no obvious way to repair the WordPress install once this happens.

    Here is the fix from the support thread for 3.9.x releases, it is a simple fix though extremely annoying and frustrating for end users.

    Once you have ‘built’ your localized version of WordPress please download the release to your local PC, extract the archive and confirm that the `$wp_version = ` in `/wp-includes/version.php` matches the version of WordPress you are expecting to release, once that is confirmed then go ahead and click ‘release’.

    I know @nacin is working to resolve and improve the tools we use to avoid these types of situations and until that is the case manually verifying the version only takes an extra minute before you ‘release’.

    Cheers, Stephen

     
    • samuelsidler 7:10 am on May 21, 2014 Permalink | Log in to Reply

      Can we make it just a drop down of versions hardcoded in the interface? We don’t ship all that frequently.

      • Gabriel Reguly 7:24 am on May 21, 2014 Permalink | Log in to Reply

        The problem happens when one informs wrongly the revision number to be used on the build.

      • Stephen Edgar 7:50 am on May 21, 2014 Permalink | Log in to Reply

        No, not right at the moment.

        This is a downside of the versatility of the build tools available to the translations teams.

        A build can be built from any WordPress Core changeset, branch or tag. These can use translations from GlotPress or uploaded to the i18n.svn repo. It’s a workflow choice by each team on there method of choice.

        I’m not sure the exact enhancements on the way though the drop down is one of the things I envision per Nacin’s post here:
        http://make.wordpress.org/polyglots/2014/05/08/wordpress-3-9-1-is-out-there-are-no-string/

        • samuelsidler 2:56 pm on May 21, 2014 Permalink | Log in to Reply

          In my mind, builds shouldn’t be allowed from “any WordPress Core changeset, branch or tag” because there’s no reason for that. Building for specific versions is fine, of course, which a drop down would solve.

          Builds actually happen in an interface, regardless of where the translations come from (GlotPress/SVN), right? So we can control what gets built.

          • Stephen Edgar 2:20 am on May 23, 2014 Permalink | Log in to Reply

            Nacin has covered this in his post here, when these changes land for 4.0 all will be good, some ‘may’ even make it for a 3.9.x release, worst case scenario is a handful of 3.9.x releases will need to maintain a bit of vigilance.

    • Gabriel Reguly 7:22 am on May 21, 2014 Permalink | Log in to Reply

      Hi Stephen,

      Good call, lets hope that the build process gets improved.

  • Brad Angelcyk 4:06 pm on May 13, 2014 Permalink | Log in to leave a Comment
    irbrad
    Tags: ,   

    Hey polyglots,

    We’re releasing WordPress for iOS 4.0.3 soon and need the release notes translated.

    • Adjusted user interface for media management to allow for faster insertion of images.
    • Improved accessibility of the stats interface.
    • Launched live chat support on a limited rollout.
    • Fixed many miscellaneous bugs.

    Thanks!

     
    • Remkus de Vries 4:16 pm on May 13, 2014 Permalink | Log in to Reply

      Not sure if @nacin still needs to finish setting it up, but the Release Notes have been added to translate: http://translate.wordpress.org/projects/ios/dev/release-notes

    • daniloercoli 4:25 pm on May 14, 2014 Permalink | Log in to Reply

      it_IT:

      • Migliorata l’interfaccia utente usata per la gestione dei file multimediali, che consente ora un rapido inserimento delle immagini.
      • Migliorata l’accessibilità della schermata Statistiche.
      • Aggiunta la possibilità di contattare il supporto tecnico tramite live chat. Questa funzionalità al momento è disponibile solamente per un numero limitato di utenti.
      • Corretti diversi bug.
    • Emre Erkan 6:03 pm on May 14, 2014 Permalink | Log in to Reply

      tr_TR:

      • Görsellerin daha hızlı eklenebilmesi için ortam yöneticisinin kullanıcı arayüzü ayarlandı.
      • İstatistik arayüzünün erişilebilirliği geliştirildi.
      • Kısıtlı çıkışlar için canlı shobet desteği eklendi.
      • İrili ufaklı bir sürü hata giderildi.
    • Naoko Takano 11:41 pm on May 14, 2014 Permalink | Log in to Reply

      Still not seeing GlotPress updated, so here it is:

      ja:

      • 画像をよりすばやく挿入できるようにメディア管理 UI を調整。
      • 統計情報インターフェースのアクセシビリティ改善。
      • 限定的にライブチャットサポートをローンチ。
      • 多数の様々なバグ修正。
    • drssay 4:40 am on May 15, 2014 Permalink | Log in to Reply

      ko_KR :
      빠른 이미지 삽입을 위한 미디어관리 인터페이스 조정
      통계 인터페이스의 접근성 향상
      제한된 상황에서 라이브챗 출시
      기타 소소한 버그 해결

    • martinremy 1:00 pm on May 15, 2014 Permalink | Log in to Reply

      de_DE:

      • Verbesserte Benutzeroberfläche für den Medienmanager um schnelleres einfügen von Bildern zu ermöglichen.
      • Verbesserte Barrierefreiheit in der Statistik Anzeige.
      • Live Chat Hilfe wurde auf begrenzter Basis eingeführt.
      • Diverse andere Fehler wurden behoben.
    • Jorge Bernal 1:42 pm on May 15, 2014 Permalink | Log in to Reply

      es_ES:

      • Ajustada la interfaz de gestión multimedia para insertar imágenes más rápido.
      • Mejorada accesibilidad de las estadísticas.
      • Lanzado soporte en vivo para algunos usuarios.
      • Varios fallos corregidos.
    • Maxime 11:41 pm on May 15, 2014 Permalink | Log in to Reply

      fr_FR:

      • Meilleure experience utilisateur pour la gestion des medias. Permet d’insérer des images beaucoup plus rapidement.
      • Amélioration de l’accessibilité de l’interface des statistiques
      • Possibilité de discuter en direct avec le support (pour certains utilisateurs)
      • Nombreux bugs résolus
    • aspadm 1:12 pm on May 16, 2014 Permalink | Log in to Reply

      ru_RU

      *Изменён пользовательский интерфейс управления мультимедиа, что позволяет быстро вставлять изображения.
      *Улучшенная доступность статистики интерфейса.
      *Запущен ограниченный чат онлайн поддержки.
      *Исправлено множество других ошибок.

  • pcgaldo 9:13 pm on May 11, 2014 Permalink | Log in to leave a Comment
    pcgaldo • gl.wordpress.org validator
    Tags: privacy   

    Hi to everyone!

    I’ve received an e-mail yesterday, requesting the cancellation of some personal data on translation files and track system. Can we help Alvaro to improve his privacy?

    Good afternoon, My name is Álvaro ***** and I was translator of Twenty Ten theme. At that time I was working in a company and published my full name in the file. However, I want to delete my personal data, at least the last name: http://i18n.trac.wordpress.org/changeset/16207 I know it’s a track system, but there has to be solutions to these situations. Is there any chance? Thank you very much.

     
  • Remkus de Vries 8:41 am on May 9, 2014 Permalink | Log in to leave a Comment
    DeFries • nl.wordpress.org editor • fy.wordpress.org editor
    Tags: automatic updates,   

    Hi @nacin

    I just saw the bbPress translations being updated while updating to WordPress 3.9.1 which made me very happy. When I then updated a multi-site instance to 3.9.1 (with also bbPress activated in the network) there were no updates of the bbPress language files.

    Any idea why I would have two different outcomes?

     
    • Ze Fontainhas 8:47 am on May 9, 2014 Permalink | Log in to Reply

      Not sure I get it. Why would a WordPress update change bbPress’ language files? Remember that before bbPress releases a new version, you can always export those from Translate and update bbPress. Or am I seeing this wrong?

    • Marko Heijnen 7:08 pm on May 9, 2014 Permalink | Log in to Reply

      I saw the same. I also seeing the issue that it was downloading the dev version and not the 2.5.x one.

      • Stephen Edgar 10:47 am on May 10, 2014 Permalink | Log in to Reply

        Boom! This is awesome, I hadn’t noticed this and have just now been playing :)

        I had an en_US (default) multisite test setup and switched it to en_AU and I got the translations for Akismet, bbPress & BuddyPress

        So multisite worked for me and not for @DeFries

        After close inspection of the headers in the bbPress .po file I believe the translations are via GlotPress’ bbPress 2.5.x tag though @markoheijnen got the /dev translations.

        No doubt this will need more testing as running bbPress /trunk I’d expect to get the /dev translations (even if they are only partially translated )

        Massive thanks @nacin and please thank anyone else involved we are not aware of :)

        If there is a Trac ticket to track this let me know and I’ll test the daylights out of all the permutations and combinations :)

        @vanillalounge Automatic Translations Updates #FTW http://make.wordpress.org/core/2013/09/24/automatic-core-updates/

        p.s. This is one of the primary reasons I created the en_AU translations to make sure we have bbPress and BuddyPress deliver automatic translations.

        • Remkus de Vries 11:48 am on May 10, 2014 Permalink | Log in to Reply

          Indeed, major props to anyone involved in getting these updates working. REALLY happy with it and I trust these bugs will be ironed out. Someday ;)

  • Nick Weisser 12:59 pm on May 4, 2014 Permalink | Log in to leave a Comment
    openstream • gsw.wordpress.org validator • de-ch.wordpress.org editor
    Tags: ,   

    Hey Remkus, I’d like to request a new Rosetta site de-ch.wordpress.org. I’ve imported the formal translations for Swiss German on translate.wordpress.org. Please let me know what the next steps would be. Nick

     
    • Kevin Kyburz (@swissky) 8:29 am on May 5, 2014 Permalink | Log in to Reply

      the formal version can indeed run over gsw.wordpress.org. de-ch.wordpress.org I had already discussed at WordCamp Europe with Ze

    • Kevin Kyburz (@swissky) 8:33 am on May 5, 2014 Permalink | Log in to Reply

    • openstream 10:40 am on May 5, 2014 Permalink | Log in to Reply

      I have just imported the formal one for the admin section in dev, too. But for some reason http://translate.wordpress.org/projects/wp/3.9.x/admin is still only showing a blank page.

      Regarding Rosetta page: I think the ZIP should contain the formal Swiss version of the .po files. If someone then installs WordPress from the official Swiss German ZIP he/she will also see the Swiss German blog postings on the admin dashboard widgets.

    • Ze Fontainhas 1:29 pm on May 5, 2014 Permalink | Log in to Reply

      This is getting confusing, real fast. For the sake of clarity:

      What is the purpose of gsw and de_CH? Please see http://www.ethnologue.com/country/CH/languages for disambiguation. Is it that de_CH is significantly different from both de_DE and gsw? I’m asking because there is no mention in Ethnologue of a version of Swiss German somewehere between Standard German and Schwyzerdütsch. Might this be just a matter of formal vs. informal variants of gsw?

      the formal de_CH version would most like be more used than the informal one currently available and thus would deserve a proper site.

      I’m not so sure. Other languages have variants (pt_PT and de_DE, at least), and those do not usually warrant a separate site. Remember that an additional site requires additional maintenance. Granted there is the question of packaging releases, which isn’t variant-aware, but maybe @nacin has plans or can recommend a sensible approach to this.

      for some reason http://translate.wordpress.org/projects/wp/3.9.x/admin is still only showing a blank page.

      Looks like a bug to to me, but there’s been some activity on the GP repo lately, maybe @yoavf or @markoheijnen can take a look.

      • Remkus de Vries 4:29 pm on May 5, 2014 Permalink | Log in to Reply

        I’m not so sure. Other languages have variants (pt_PT and de_DE, at least), and those do not usually warrant a separate site. Remember that an additional site requires additional maintenance. Granted there is the question of packaging releases, which isn’t variant-aware, but maybe @nacin has plans or can recommend a sensible approach to this.

        The “treating it as a separate site” came from the wish to do proper releases and the expectation the formal version would actually find itself on more installations than the informal.

        Looks like a bug to to me, but there’s been some activity on the GP repo lately, maybe @yoavf or @markoheijnen can take a look.

        Regarding the bug, I’m guessing it has something to do with copying dev to 3.9 project in GlotPress?

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

        I do indeed have near-term (4.0) plans to fix up all release packaging, including locale variants.

      • Nick Weisser 5:03 pm on May 5, 2014 Permalink | Log in to Reply

        Although occasionally you will find websites or books published in spoken Swiss German (ISO code gsw), most publications including newspapers are written in de_CH, i.e. formal German with de_CH spelling which slightly differs from the de_DE spelling. As far as I understand de.wordpress.org is de_DE. For Austria the difference between de_DE and de_AT might be neglectable, but I’m sure there are people who will also disagree with that :-)

        I’m maintaining the de_CH language pack for Magento and think it absolutely makes sense to have a separate language pack for de_CH, because not only the spelling is different (ss instead of ß), but also some of the words are different, e.g. Kanton instead of Bundesland.

        When building an e-commerce website based on WordPress there’s one more aspect that comes into play, i.e. number formatting. You need to configure the de_CH locale in a Swiss store, because floating numbers like 1.25 are formatted the same way as in the US, whereas in Germany and Austria they are formatted with a comma, i.e. 1,25.

        I’m not sure how other countries with more than one official language handle this (Switzerland has 4 official languages), but another reason for having our own Rosetta site is the country specific blog postings which are pulled into the “WordPress News” section of the admin dashboard of Swiss German (de_CH) WordPress installations.

        If I install the regular German ZIP package of WordPress I see German “WordPress Nachrichten” in the dashboard with events in Hamburg that are not necessarily relevant for Swiss WordPress users. So either the Swiss WordPress community would have to post their stuff on blog.wpde.org (as de.wordpress.org has no blog postings) or on ch.wordpress.org.

        So in conclusion the best thing for Switzerland would actually be the Rosetta site ch.wordpress.org for all 4 official languages where you can download 4 different ZIP archives, one for each language. If that does not make sense, the 2nd best option would be de-ch.wordpress.org and if that does not make sense either, we would probably have to create our own “inofficial” domain where we gather the ZIP archives for all 4 official languages and can provide a Swiss WordPress news blog, too.

        • Ze Fontainhas 5:58 pm on May 5, 2014 Permalink | Log in to Reply

          This argument makes a lot more sense, thank you for that. We’ll implement de_CH, but I’ll still need it in the proper request format.

          Some notes:

          For Austria the difference between de_DE and de_AT might be neglectable,

          It’s not, and never, ever say this to an Austrian, much less a Viennese :)

          the Rosetta site ch.wordpress.org for all 4 official languages where you can download 4 different ZIP archives, one for each language

          This is not doable right now, the best we can do is offer a de-ch.wordpress.org. Not only can we not do “country” Rosetta sites, nor can we do “meta-language” Rosetta sites (think a new fr, de or pt Rosetta site, that would list all variants of a language). That said, the necessity is clear (even if the priority mightn’t be) and I’m all for discussing what it would take to have those available.

    • Nick Weisser 7:15 am on May 6, 2014 Permalink | Log in to Reply

      Thanks a lot, Ze. I saw that you already added it to https://glotpress.trac.wordpress.org/browser/trunk/locales/locales.php

      For French there is French (France), French (Canada), etc. so it could also be named German (Switzerland). Anyway, very glad we can now start building the Rosetta page. Very much appreciated!

  • Wacław Jacek 6:08 am on April 24, 2014 Permalink | Log in to leave a Comment
    waclawjacek • pl.wordpress.org editor  

    What’s the current status of the 3.9.x branch at translate.wordpress.org? Should I build 3.9 from the “3.9.x” branch or from “Development”?

     
  • Ze Fontainhas 2:21 pm on April 16, 2014 Permalink | Log in to leave a Comment
    vanillalounge • pt.wordpress.org editor  

    I’m receiving a bunch of Rosetta Deploy Requests, and this usually happens just before a new release. Please keep in mind that deploying rosetta is in no way related to building and releasing a new package. The process simply and only deploys translations of your xx.wordpress.org site itself.

     
  • Xavier Borderie 10:20 am on April 16, 2014 Permalink | Log in to leave a Comment
    xibe • fr.wordpress.org editor  

    I am receiving reports that the fr_FR translation is not being “pushed” correctly (the WP update itself goes fine).

    Apparently, WordPress still displays the “Update now” message when in fact only the translation has to be updated.
    I myself have seen translations not being updated on my sites in the past.

    I am currently gathering information — I’m unsure if this is about 3.8.x or 3.9-RC2-fr_FR (which we released yesterday).

     
    • Remkus de Vries 10:24 am on April 16, 2014 Permalink | Log in to Reply

      We’re experiencing the same thing for nl_NL and I suspect what’s happening is that the normal version is being used for the update and then later on when the localized version is available it will prompt again.

      Is something off on the wp.org side of things @nacin?

    • Xavier Borderie 10:50 am on April 16, 2014 Permalink | Log in to Reply

      I had feedback only on 3.8.2 and 3.8.3 (not sure for 3.8.1). All had WordPress installations with minor updates done in automatic mode.

      Emails about the update having been done are received, and indeed the update is done, but WP still shows that an update is available (in the Dashboard). The fr_FR version is then proposed.

      It’s as if any update downloads the en_US version without the fr_FR translation.

      I also get feedback of typos that were corrected in 3.8.0 or 3.8.1-2 but which are still present. It really does seem that translation are not being updated correctly.

      • Petya Raykovska 11:57 am on April 16, 2014 Permalink | Log in to Reply

        I’ve been having the false update notification problem ever since 3.8. The version is the latest, but the Dashboard shows an available update system msg.

        Also – strings I personally made sure were changed and corrected still appear here and there.

    • Sergey Biryukov 12:57 pm on April 16, 2014 Permalink | Log in to Reply

      • Xavier Borderie 1:04 pm on April 16, 2014 Permalink | Log in to Reply

        @sergeybiryukov : correct me if I’m wrong, but I am unsure this is the main issue. If the automatic translation update worked correctly, we wouldn’t even have to decide between two options. So far, it seems that translation update is not working correctly.

  • Andrew Nacin 6:37 am on April 16, 2014 Permalink | Log in to leave a Comment
    nacin
    Tags: , ,   

    WordPress 3.9 is being released at 1700 GMT, or about 10 hours from now.

    I’m sorry you didn’t get more lead time on a few strings. I recognize there has been some string flux over the past week, as a result of the about page, some strings that had gone untranslated accidentally, etc. Just wanted to say I know how much time you put into these and thanks for all you do.

    After 3.9 I’ll be spending a few weeks working primarily on localization and internationalization, so expect some exciting things. :-)

     
  • Victor J. Quesada 8:58 pm on April 14, 2014 Permalink | Log in to leave a Comment
    egalego • gl.wordpress.org editor  

    problem compilating new versions
    error…

    https://gl.wordpress.org/

    http://gl.wordpress.org/files/2014/04/fallowp3.png

     
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