WordPress.org

Ready to get started?Download WordPress

Translate WordPress

Updates from May, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 12:25 pm on August 27, 2014 Permalink | Log in to leave a Comment
    nacin
    Tags: , ,   

    WordPress 4.0 RC is out.

    In a few hours I’ll be building new language packs for RC1 for any locale at 100% for the wp/dev project and all sub-projects (this includes the network admin). Each day as translations are completed, packs will be created or updated. We’ll work out some kinks over the next few days and hopefully have everything in order come September. Expect to hear more from me in the coming days and weeks as we begin a new journey. :-)

    @helen is targeting September 3 for release. The about page is done, help tabs are updated, and strings are frozen. You have one week to get everything in order, so good luck and happy translating!

     
  • Kazama 7:22 am on August 21, 2014 Permalink | Log in to leave a Comment
    kazama • th.wordpress.org editor  

    Just saw http://translate.wordpress.org/languages. I really love it, this is what I really want. :P

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

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

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

     
  • Ze Fontainhas 3:07 pm on August 11, 2014 Permalink | Log in to leave a Comment
    vanillalounge • pt.wordpress.org editor  

    Trying to wrap my head around the 4.0 silence, here are a few personal thoughts. They’re not directed at anyone in particular, as I can’t judge other factors that may be impacting the issue, and are just an attempt at trying to summarize the issue (this one issue, obviously; there are others):

    • 4.0 is coming and we have, yet again, no string freeze
    • We have no Dev project in Translate with 4.0’s strings
    • It’s August. In many places around the world people are on holidays, which makes the effort to translate and validate what will most certainly be a torrent of new strings nearly impossible
    • We keep hearing about (and seeing in betas) the monumental (and very laudable) effort to focus on localisation
    • We were announced this: no one on polyglots that I know was involved in any kind of defining discussion prior to this announcement
    • As far as I can tell, no polyglot is involved in the current discussion either. Granted, this may be due to a lack of initiative to participate, but, given the above, an understandable one
    • The bare minimum would be to provide some feedback. We all understand that schedules are tight and contribution is voluntary, but a little heads-up goes a very long way.

    Summing up, what we see is our work, defined outside this group, piling up, with what seems the expectation that “oh, polyglots will translate when everything else has been taken care of”, apparently oblivious the fact that we’re responsible for providing WordPress for more than half of total downloads worldwide.

    If you feel that you have something to add, do discuss the points as you see fit, but please keep the debate civil, polite and constructive. We all (and I mean all) work hard, disrespect has no place here.

     
    • Remkus de Vries 3:16 pm on August 11, 2014 Permalink | Log in to Reply

      Having just returned from my holiday I am surprised to see we’re not one step further than three weeks ago with this … which makes me sad :(

    • Xavier Borderie 4:59 pm on August 11, 2014 Permalink | Log in to Reply

      Thanks for this summary, Zé.

      A positive aside might be that, since the new system was announced in May as:

      • Not having per-language builds.
      • Not having language-separate “Update” buttons in the admin.
      • …in addition to being able to update the translation separately (which I have yet to witness working, but still)

      …it might be that being at 100% on D-Day is not as important for further releases (4.0 onward) as it was in the past.

      Still, knowing how all of this will work (or whether all the good stuffs announced in May are ready or not) is a must in this shortening timeframe.

      • Mattias Tengblad 5:29 pm on August 11, 2014 Permalink | Log in to Reply

        Disagree, being at 100% on release is still as important. I for one wouldn’t wont something else than 100% at release.

        • Xavier Borderie 5:58 pm on August 11, 2014 Permalink | Log in to Reply

          I agree with you 100% (ha!), I’m only stating this because not having day-0 full translation might be what the new system is being built to help us with (sorry for the weird sentence, hm).

          But really, for all we know, it could be something totally different — we haven’t had much news since the May announcements.

          • Mattias Tengblad 7:40 pm on August 11, 2014 Permalink | Log in to Reply

            Ah, ok. Get what you mean now.

          • Andrew Nacin 3:48 am on August 14, 2014 Permalink | Log in to Reply

            The system isn’t designed for being sub-100% when the release comes. While it does handle that situation, it is actually designed for these three use cases:

            1. You’ve finished translating WordPress 4.x with a week to spare. Congratulations! When it gets released, you don’t need to do a thing — if your translation is at 100%, it will automatically be packaged up for you. No more rushing to package things up.

            2. You noticed a pretty glaring typo the day after a major release. You can go ahead and fix it. The download packages and the language packs will automatically be updated (within a day or a week or a push of a button — this is up for discussion and it’s trivial to do any of these) and sites will automatically be updated to them.

            3. A security release needs to come out. You don’t need to do a thing at all. There will be no new strings, and the scripts will handle building your new 4.0.2 packages to be available for download.

            Essentially, the idea is to get you out of release management and allow you to spend your time translating and building your local communities.

            • Naoko Takano 5:59 am on August 14, 2014 Permalink

              I’m curious how packages that still require special modification are going to be handled (e.g. Japanese pkg still needs WP Multibyte Patch). Will the automated packaging process include /dist/ directory for these locales?

    • Marko Heijnen 5:36 pm on August 11, 2014 Permalink | Log in to Reply

      We need communication between core and polyglots and not having core working on their issues and we do here only translations. The internationalisation teams should be more then that.

    • Gabriel Reguly 5:40 pm on August 11, 2014 Permalink | Log in to Reply

      Nice post Zé, but will it be effective?

      Because there are posts on other places that also got the 4.0 silence. :-(

      (http://make.wordpress.org/core/2014/08/06/proposed-agenda-for-todays-dev-chat-3-9-2/#comment-17458)

      Maybe @helen could be sensibilized if we all politely show up at the next dev chat?

      • Andrew Nacin 3:51 am on August 14, 2014 Permalink | Log in to Reply

        I’m in charge of all i18n. There was some silence because I was busy cleaning up after the security release last week (which I spent a few weeks beforehand managing) and then there was a weekend.

    • Stephen Edgar 12:12 am on August 12, 2014 Permalink | Log in to Reply

      I’m with you regarding the fact that there is no 4.0 /dev branch to translate strings yet. :(

      Not so much on the other parts. I believe @Nacin clearly laid out the goals and at the time asked “I’ll need a lot of help”. I would also say that with the vast majority of each of these goals included were links to the relevant tickets on Trac.

      I am subscribed to the i18n component on trac and receive an email for every single ticket and comment for the i18n component. I am participating and contributing to the i18n component where and when I can all the time and thus this also includes the 4.0 goals, be it adding patches (when I can), feedback or testing.

      In my opinion the place to contribute towards these “i18n 4.0 goals” is on WordPress Trac, in each individual ticket, for each bit of functionality and not have fragmented discussions here on Polyglots P2.

      • Mattias Tengblad 1:42 am on August 12, 2014 Permalink | Log in to Reply

        You are making the assumption that every translator is a developer.

        • Petya Raykovska 10:18 am on August 12, 2014 Permalink | Log in to Reply

          You don’t have to be a developer to follow trac and give feedback.

          • Ze Fontainhas 10:24 am on August 12, 2014 Permalink | Log in to Reply

            That is a whole other discussion. I’m with Mattias on this one: you probably do.

            • Stephen Edgar 11:58 am on August 12, 2014 Permalink

              Ze, my original reply was a touch longer and I had originally included something similar to what I think you are alluding to here but was not happy with how I was articulating my point in this regard so I removed that section.

              Much of the i18n 4.0 goals are not just a thing for the “Polyglots” team, theoretically these would also involve the “Accessibility” and “UI” teams also and not forgetting the “Core” team.

              I agree that Trac can be a difficult place to navigate but be it code, design, functionality, testing or feedback this all needs to happen somewhere and fragmenting the discussion in multiple locations is not easy for anyone to keep on top of.

              Each feature or part thereof should be in a single location where it can be scoped, coded, tested, receive feedback and finally committed and in the WordPress world of things that place is Trac.

              Trac has become friendlier with recent improvements such as being able subscribe to a particular component or focus of interest but as you state this is a whole other discussion.

            • Mattias Tengblad 2:34 pm on August 12, 2014 Permalink

              Putting Stephens comment against Zé’s comment below.

              Stephen feel that everything should be done in trac (even the planing?)

              Zé is pointing out that trac tickets shouldn’t be used for general questions about functions being developed.

              I’m seeing contradictions in this workflow. What is this P2 for? Only access requests?

              In my mind trac should be used as it is, for the development specific parts, not the general discussions. Development specific chatter in a general translator discussion and vice verse makes things very hard to follow for each group (assuming they only have knowledge in their area).

              How many of the polyglotters are actually active on trac? Not many. To then just blindly refer to trac as many core members are doing is not constructive at all.

              Is it really that hard to setup a irc chat session between core and polyglot, for planning and reconnaissance of workflow for i18n and the language teams when things change?

              @petya of course not, but still, trac is development oriented and not everyone feels confident commenting on tickets. One should not dismiss that there are problems with this approach given that these discussions continue to occur.

            • Ze Fontainhas 3:47 pm on August 12, 2014 Permalink

              I was originally replying to @petya, but ok. I still think you’re coming from a developer mindset, but i grant you that it is wholly subjective.

              Now, as to:

              …code, design, functionality, testing or feedback this all needs to happen somewhere and fragmenting the discussion in multiple locations is not easy for anyone to keep on top of.

              It certainly does, and Trac is certainly the place for that. What you’re not taking into account is that I’m referring to the moments prior to that: the goals were announced, not discussed, nor was there any previous hint that they might drop: they were suddenly there.

              Trac has become friendlier with recent improvements

              Indeed it has, but the issue is not one of features, but rather of population: It takes a significant psychological shift to start or participate in a discussion in Trac. It is no coincidence that practically every WordCamp has a talk or a hack day sessionon how to contribute on Trac, and not be afraid of the people there.

              Trac is a crucial component, as is moving the tickets along with constructive debate. It is not, however, a place for conceptual conversations around features.

              Developers tend to not see that distinction.

            • Petya Raykovska 5:14 pm on August 12, 2014 Permalink

              Do you think we can come up with a process and change the need for people to go on trac and follow and participate in discussions?

              If these problems keep occuring perhaps we could figure out a way to interact with the core team and keep people on the Polyglots blog better informed?

              Like:

              • Someone keeps an eye on trac i18n tickets (Stephen already does!) and gives a regular summery on the p2 on the developments if things need to be discussed
              • If the topic is tricky or conflicting, we schedule a chat with core team to better get what they’re thinking?
            • Stephen Edgar 4:07 am on August 13, 2014 Permalink

              @damst, @vanillalounge @petya Thanks, I think pretty much everything written in reply to my last reply are good points and should be worked on, developed, fleshed out further on how the Polyglots team wants to ‘contribute’ more than just translations to WordPress Core.

              Not all that long ago I would say the Accessibility team faced similar issues to what we are generally talking about here. Now they hold regular weekly IRC chats and post updates their P2 blog. The ‘Core’ team knows about this chat and I’ve seen @Helen swing by with specific requests during those IRC chat’s.

              So maybe this would be the obvious first steps for Polyglots, start idling in IRC more, having a weekly chat (or two for people’s time zone differences), and make ourselves more available and to more teams across the WordPress project. That can then be a starting point do discuss how the Polyglots team can best achieve it’s team goals.

      • pavelevap 8:47 am on August 12, 2014 Permalink | Log in to Reply

        I also tried this way and made several tickets related to current localization, for example:

        https://core.trac.wordpress.org/ticket/28723
        https://core.trac.wordpress.org/ticket/28571

        So, reinstalling WordPress does not work for localized versions. Language files in wp-content/languages are automatically overwritten (yes, really, please be carefull when using Poedit because you can LOST your work in a sec), etc. Nobody interested in Trac…

        And comments:
        https://core.trac.wordpress.org/ticket/28577#comment:43
        https://core.trac.wordpress.org/ticket/28577#comment:47

        Nobody answered and I am not a developer.

        • Ze Fontainhas 10:23 am on August 12, 2014 Permalink | Log in to Reply

          Hold on. Only #28723 is silent. #28571 has an active discussion going on. As to the comments in #28577, they seem to simply be out of place, hijacking the thread. Fair is fair and your comment gives the wrong impression.

    • pavelevap 12:14 pm on August 12, 2014 Permalink | Log in to Reply

      Sorry, but #28571 is not active discussion. I described some problems there (with major one related to overwriting localization files) 2 months ago and several users added the same observations. This should be resolved before first beta and not several days before official release.

      And in #28577 I tried to raise the same questions as on Polyglots and other tickets, because it is the only active i18n ticket. Second comment is not ticket hijacking, I asked how to change language name for language installer and still no reply.

    • Mattias Tengblad 1:25 am on August 14, 2014 Permalink | Log in to Reply

      Interesting read https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-08-13&sort=asc#m905811

      I am somewhat concerned about the attitude displayed by some core members, but at the same time happy that others are trying to change the situation.

  • pavelevap 9:57 am on August 7, 2014 Permalink | Log in to leave a Comment
    pavelevap • cs.wordpress.org editor  

    How will WordPress 4.0 language installation work? I probably did not understand it fully, so I am asking:

    1) Localized version will be ready several days after release of WordPress 4.0. Which language pack will receive new users in the meantime? Older (and complete) 3.9 language version?

    2) There will be any button, that localization is complete or there will be many different translations? I do not want to allow not finished localization for distribution.

    3) When I change some strings in GlotPress, all users will be automatically updated (every day)?

    There are only 2 week to WordPress 4.0 release and there is no discussion with translators how it should work. And also no detail information :-(

     
    • Mattias Tengblad 12:15 pm on August 7, 2014 Permalink | Log in to Reply

      +1

      Two weeks before a major release and this is not clear at all.

    • Stefano Aglietti 2:58 pm on August 7, 2014 Permalink | Log in to Reply

      +1 Nacin should start to give us info ASAP in Europe lot of people is on vacation this period translators too… and some planning is necessary!

    • Michael Beil 5:52 pm on August 7, 2014 Permalink | Log in to Reply

      I don’t know if y’all saw this, but there’s a whole discussion that @nacin posted that is dated May 21, 2014 going on over here: http://make.wordpress.org/polyglots/2014/05/22/internationalization-goals-for-wordpress-4-0

      This is connected to http://make.wordpress.org/core/2014/05/21/internationalization-goals-for-4-0/

    • pavelevap 7:17 pm on August 10, 2014 Permalink | Log in to Reply

      Problem is not only translation, but we should also try releasing and testing beta versions, discussing best workflow etc. Now there will be some process defined by developers and we will have to hurry to finish translation and not to discuss many other important things related to automatic language packs.

    • Andrew Nacin 3:43 am on August 14, 2014 Permalink | Log in to Reply

      1) Localized version will be ready several days after release of WordPress 4.0. Which language pack will receive new users in the meantime? Older (and complete) 3.9 language version?

      Some of this isn’t completely worked out yet — versions are a real pain to get “right” from both technical and UX standpoints. Essentially, yes, new users will receive the 3.9 version until the 4.0 is complete.

      2) There will be any button, that localization is complete or there will be many different translations? I do not want to allow not finished localization for distribution.

      If a language is 100% before release, then it will be immediately packaged upon core release. That’s all that needs to be done. Once 100% is hit post-release, a scheduled task will package these up. It will likely run once per day, except on or around release days when it’ll run as languages rush to finish up. This is all easily adjustable based on how things are written.

      3) When I change some strings in GlotPress, all users will be automatically updated (every day)?

      Yes, users will be automatically updated. Whether that’s every day, every week, or with the push of a button is up for discussion. I expect there will be a lot of tweaking in the coming months.

      • pavelevap 9:05 am on August 14, 2014 Permalink | Log in to Reply

        Thank you!

        Ad 2) OK and it is related to all subprojects? We have 100% for frontend, around 90% for backend (takes longer to translate all long help sentences) and a very little for multisite admin (10 %). So in this case there will be only frontend file distributed? It will be regression because there will be missing 90% of backend? And another use-case: I need to distribute language for 4.0 when it is 97% complete (new features translated, but About page with long sentences not yet). How can I do it? We really need a “button” to tell “Start distributing” to script. No need for building packages, but some human work is needed here…

        Ad 3) And what is checked from technical point of view? Date of latest string change in GlotPress? Comparing with date of latest language pack updates?

        • Andrew Nacin 5:23 am on August 15, 2014 Permalink | Log in to Reply

          2) As of right now, it needs to be 100% for all sub-projects (frontend, admin, network admin). But I suspect we’ll add a button. Thanks for the feedback.

          3) Yes, the date in the PO file headers are used and compared with the latest string change in GlotPress (across all sub-projects).

          • pavelevap 6:36 am on August 15, 2014 Permalink | Log in to Reply

            ad 2) Thank you, button would be really helpfull. Instead of packaging the whole localized version, there could be a simple checkbox for every MAJOR version (minor can work automatically). It is still great improvement for translators, only one checkbox per project (for WordPress it should combine all subprojetcs), no problem with handling minor versions, etc. Translators could check when they think it is done and distribution can start.

            ad 3) Nice, it would be fine to distribute typos corrections automatically. But when user change .po file (and modify it), then this date will be newer than GlotPress?

          • Kenan Dervisevic 10:43 am on August 15, 2014 Permalink | Log in to Reply

            @nacin What about readme and wp-config? How will that be handled?

  • 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.

    • akerbeltzalba 10:46 am on August 7, 2014 Permalink | Log in to Reply

      Our locale is sort of guilty (http://gd.wordpress.org v 3.5.1) but I have a suggestion. Could we please make building the new packs automatic or at least ‘press this button to build your new release’? There are many localizers on WordPress who are perfectly happy to maintain translations but who struggle with building the actual packs. I am an extremely good translator but not good at developer stuff and new releases are relatively infrequent so that even with my notes, every time I want to release one, I struggle and then have to fine someone who can help me.
      Most other projects like Mozilla have a simple signoff process (just a click by locale leader) or LibreOffice (automatically included if translation above a certain %). Something like that would go a long way to making sure the newest releases are on offer by all locales.

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

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