WordPress Polyglots

Tagged: 3.4 Toggle Comment Threads | Keyboard Shortcuts

  • Stefano Aglietti 7:37 am on August 23, 2012 Permalink | Reply
    SteveAgl • it.wordpress.org editor
    Tags: 3.4, disaster, empty   

    SIGH :( I see the development version was made and that’s good :) But… 3.4 now are fully empty and during last weekes for italian people have submitted a lot of revisions that are gone forever if there is no backup :(

     

    • Ze Fontainhas 8:50 am on August 23, 2012 Permalink | Reply

      I should’ve warned, sorry. All history of 3.4.x is kept in the new dev project. I’ll be re-populating 3.4.x soon.

    • Stefano Aglietti 9:05 am on August 23, 2012 Permalink | Reply

      opps sorry i wrote wrong… i was referring to 3.3.X i didn’t check 3.4 yet :)

  • Eivind Ødegård 3:44 pm on June 28, 2012 Permalink | Reply
    meinmycell • nn.wordpress.org editor • nb.wordpress.org validator
    Tags: 3.4,   

    In Glotpress, I see 40 untranslated strings for WP 3.4 nn_NO, but the list of untranslated nn_NO strings is empty. Any ideas?

     

  • Andrew Nacin 8:16 pm on June 27, 2012 Permalink | Reply
    nacin
    Tags: 3.4, ,   

    3.4.1 has just been released. No string changes. There is a 3.4.x project in GlotPress for you. The revision is 21156 for either tags/3.4 or branches/3.4. This is a security update, so speed is important. Cheers!

     

  • 8:31 am on June 27, 2012 Permalink | Reply
    steagl
    Tags: 3.4   

    Why till today on glotpress there is no 3.4 branch and 3.5 but we are still at 3.3.x and 3.4 with this last one that is a 3.5alpha? Is going to be realsed 3.4.1 and we have to struggle with version to generate packages with right tag. Since last week when i asked about it noone answered… why? Pls we need an answer

     

    • Wacław J. 9:11 am on June 27, 2012 Permalink | Reply

      • SteveAgl 10:02 am on June 27, 2012 Permalink | Reply

        I read it and i generated the italian 3.4 version… but i would like to get an official answer and the reasons why the glotpress is still unupdated… for year i generated the version using svn and all was under control, I was very happy for glotpress that made release easier than before.. but i would like to see more care for translation people that do a lot of work to spread the Word

    • Da^MsT 9:20 am on June 27, 2012 Permalink | Reply

      Another reason that shows that we are definitely not ready for the full switch to GP…

      • Zé 9:52 am on June 27, 2012 Permalink | Reply

        For all purposes we already did, I’m afraid.

    • Zé 9:51 am on June 27, 2012 Permalink | Reply

      Because it takes time and we all have other lives that need tending to. Also, I wouldn’t describe finding the appropriate svn revision number as a “struggle”, it’s a simple process. Be it as it may, we’re working on it.

      • SteveAgl 10:05 am on June 27, 2012 Permalink | Reply

        That take time i can agree… taht you have other lives… but it’s a non answer… all translation team try to give local version as fast as possible… we do on volunteer basis… if after the release someone wrote here explaining that glotpress will be updatedin weeks and why… noone would have said a word… i already asked about this problem and noone ansered but some other volunteer did… anyway thank for the answer

      • Wacław J. 10:06 am on June 27, 2012 Permalink | Reply

        It would be nice if the GP branch (“project?”) was created ASAP though (but no pressure), so that strings that go missing during the development of 3.5 don’t get lost.

    • Andrew Nacin 2:56 pm on June 27, 2012 Permalink | Reply

      There’s no 3.4.x project yet because I wanted to make sure we created the “branch” in a way that is smarter than what we’ve done in the past. Basically, I want to prevent you guys from re-importing everything into the branch, which is no fun, as well as maintaining history in a better fashion than the current pomo import.

      No strings have been touched in 3.5 yet, and I actually paused the script to prevent trunk from overwriting things until we branch in GP. This should go ahead soon.

  • Andrew Nacin 6:39 am on June 26, 2012 Permalink | Reply
    nacin
    Tags: 3.4,   

    [ Edit: I no longer need an answer to this question. ] All translators — Did anyone have a locale.php file (like ru_RU.php) in 3.3 that they no longer included in 3.4? If so, what is your locale? Those files are going to sit there (and be included) after an upgrade, so we need to remove them manually: http://core.trac.wordpress.org/ticket/20974. Unfortunately it is not easy to ascertain which locales used to have them but no longer do.

     

  • DjZoNe 7:28 am on June 25, 2012 Permalink | Reply
    djzone • hu.wordpress.org editor
    Tags: , 3.4, ,   

    Hi, when will be a 3.4 sub-project created on GlotPress?

    Because, if I build a package from development branch, it will end up with 3.5-alpha package, and the next branch is 3.3, which will end up a 3.3.2 package…

     

  • Andrew Nacin 5:02 pm on June 13, 2012 Permalink | Reply
    nacin
    Tags: 3.4, ,   

    WordPress 3.4 will be released within the hour. Start your engines.

     

  • Xavier Borderie 10:00 pm on May 30, 2012 Permalink | Reply
    xibe • fr.wordpress.org editor
    Tags: 3.4,   

    I’m seeing two unknown names in the 3.4 credits: along with the historical fr_FR translators (with their pictures), I’m seeing two other names — that are not even present in the fr.wp.org users. How come?

     

    • Andrew Nacin 10:05 pm on May 30, 2012 Permalink | Reply

      Anyone with a Validator role or above on fr.wordpress.org are listed as validators. (They’re the ones with the gravatars.) Anyone who submitted a string since 3.3 was released (so December 10) get their names listed, as long as the string was approved (even if the string is no longer current).

      • xavier 10:43 pm on May 30, 2012 Permalink | Reply

        Ah, right, forgot about GlotPress again. Thanks for the reminder, Andrew!

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

    I think we are going to turn off the SVN builder for 3.4.

    You will still be able to use your SVN directory, and we will continue to pull files from /dist (like readme.html and wp-config-sample.php). But, in order to create a build, you will need to import any po/mo files you have into the wp/dev projects at translate.wordpress.org.

    GlotPress is all about collaboration. So others may help, it is preferred that you periodically import your po/mo files there (if you work with a separate tool), rather than importing them at the end in order to do a release. This also isn’t just about collaboration. At some point, I’d like to make it so you can mark your locale as “ready” for a release. Then we will simply create the build for you when we release WordPress.

     

    • Gabriel Reguly 5:29 pm on April 4, 2012 Permalink | Reply

      Hi Nacin,

      That is great news.

      But please test the GlotPress build option thoroughly before disabling the option do use the SVN builder.

      See, it was not working well for both 3.3 and 3.3.1, so I had to make the pt_BR build using the SVN option.

    • Xavier 10:44 pm on April 4, 2012 Permalink | Reply

      Can’t say I’m too thrilled about this move. But while I don’t see how it it necessary to make us use GlotPress as the One Tool (import questions aside), I can’t say I wasn’t seeing this coming sooner or later.

      • Andrew Nacin 11:18 pm on April 4, 2012 Permalink | Reply

        It is necessary because:

        There are many things we have in mind that make more sense if they were centralized in a single web-based tool (and that’s coming from someone who loves Subversion and uses it every day).

        For example, files like wp-config-sample.php and readme.html could become managed through an screen in Rosetta, rather than via Subversion. Ideally, you should not need SVN at all to manage a translation — that’s the end goal here. Also, we are now sending a number of strings into POT files that aren’t actually strings, like timezones, character vs word counting, and more. I would like to make those appear differently in GlotPress. I am already monitoring these values with simple database queries, and with GlotPress, we can even do things like special validation and views.

        When we begin to expand to crowdsourcing the translation of plugins and themes, we’re going to continue to expand our use of GlotPress. SVN will not be involved. It can’t scale in the technical sense and more importantly when it comes to learning curves and barriers to entry. We should all be using the same product and be on the same page. (As you said, it was going to happen sooner or later.)

        Another thing is to consider security and validation, to help ensure that bad or broken things don’t get into strings. If it goes through GlotPress, we can evaluate everything on a string-by-string basis and it all sits nicely in a database. If it goes through Subversion, we cannot. This is very important especially as we begin to open up translate.wordpress.org to plugins and themes.

        And so I ask, why aren’t you thrilled about this move? I understand this will change your workflow in particular (even if all you need to do is import a few PO files, which will take 2 minutes). So I would appreciate some specifics, as maybe I can help.

        • Xavier 9:53 pm on April 9, 2012 Permalink | Reply

          Oh, no worries, I hear your points loud and clear, as I do Zé’s, and completely understand that comes a time when you need to focus your energy on the most manageable and accessible tool, which SVN clearly is not for newcomers.

          As you said, this is more a question of workflow: I for one like to use Poedit (and even donated to the project :) ), and the GP interface just doesn’t do it for me. As such, I’d hate to see SVN support go the way of the dodo, but again, I’m sure this time will come.

          So, while I’m an old man who sees his world start to crumble, I do sincerely welcome the forward-looking thinking behind this decision, and support it. I also am glad to see you Andrew taking care of our ageing community. Go youngsters! :)

      • Zé 12:06 am on April 5, 2012 Permalink | Reply

        You also have to keep in mind that the profile of people willing to donate their time to translating WordPress isn’t necessarily one that has a working knowledge of SVN. Granted, many of us do, but the reason for that is both historical and fading away, i.e. in the beginning the ones translating were very often developers who needed a localized version, and even if they did not know SVN, they were familiar with the mindset required to learn it. As the number of languages and audience of WordPress grows, so is said profile shifting more towards those interested in the language itself and less in the underlying technology.

      • Mattias Tengblad 1:04 am on April 5, 2012 Permalink | Reply

        I’m with Xavier here.

        But taking Nacins post into account, I do agree with his points, just don’t think we’re there yet.

        Has there been one release where GP has not been screwing things up? Since I follow all the discussions here I’ve seen all the questions/problems with GP on release day and there for I have never used it as a source when building packages (never been any problems using SVN).

        I really want to see a well worked trough GlotPress software and an integration with the locale sites before this is happening. I don’t see GlotPress as a stable enough software yet.

        • Andrew Nacin 1:23 am on April 5, 2012 Permalink | Reply

          GlotPress does not handle release packaging. Rosetta does. And it is the same codebase, and largely the same code, that handles builds from both GlotPress and SVN. As you agree with my points, you understand why it makes sense for us to choose GP as the One Tool (as Xavier put it).

          I’ve seen just as many questions on release day about SVN. Please point me to a GlotPress or Rosetta problem that is unresolved and I will fix it. (I’m serious.)

          You guys finally have a developer who is invested on a nearly daily basis to ensure that GlotPress and Rosetta not only work, but work consistently. (That’s me, howdy!) They’re not going anywhere, so pull up a chair — we’re going for a ride. :-)

          • Mattias Tengblad 1:36 am on April 5, 2012 Permalink | Reply

            Just tried to build a package with the new changes http://wppolyglots.wordpress.com/important-changes-for-wordpress-3-4/ not working…

            Standardnyckeln i dist/wp-config-sample.php matchar inte $wp_default_secret_key i sv_SE.php. Nyckeln i sample config är:

            och den angiven i sv_SE.php är:

          • Mattias Tengblad 1:56 am on April 5, 2012 Permalink | Reply

            What I meant was that if you where using the translations from GP it screwed things up. In other words the relation, GP Rosetta ;) If those bugs are all fixed, then nice :)

            Things that needs fixing in GP:

            Loading a GP page takes ages.
            Fuzzy strings, not working at all in GP.
            Changes between versions needs to get automated, especially since importing seems to bug from time to time. Exporting -> importing between versions isn’t user friendly.

            (Maybe a bit OT, I would love to see GP as a plugin, kind of like bbPress)

            • Andrew Nacin 2:06 am on April 5, 2012 Permalink

              Loading particular pages take ages. It has been on my list to take a look. However, the slowest pages are ones that give a heads-up display of all translation sets, rather than a page that a single translator reasonably needs to be fast.

              Nothing prevents you from using your tool of choice to take advantage of fuzzy strings before GlotPress supports them. It’s just that instead of committing your PO file when you are done, you import it into GP.

              I am not aware of importing bugs. If you have an issue with importing, send me the PO file and I will test.

              I agree, changes between versions is totally lame. I am going to try to write a CLI tool that I can use to migrate all translation sets.

              GP was written as a standalone app, and it makes sense to remain that way. There really isn’t any reason to re-architect it, except to overcomplicate it and use up valuable developer time.

            • Andrew Nacin 9:16 pm on April 5, 2012 Permalink

      • Cátia Kitahara 7:10 pm on June 20, 2012 Permalink | Reply

        Lately I haven’t helped the Brazilian translation team and Gabriel has been the responsible for the releases, so I’m sorry if I’m saying something stupid. I’m back to it now, I helped translate the last release. But what I feel, is that our translation lost quality because we don’t proof read anymore. I used to do this job with a friend every new release, and we did that with poedit. We split the strings between us, like I did strings 1 to xxx and him from xxx to the end. With GlotPress this process isn’t possible. We tried to split the pages by their numbers, but then some people without admin permission sent their suggestions and them the page numbers were augmented so we didn’t know anymore which ones were lacking proof read. I don’t know if this is me, maybe I don’t know how to use GlotPress in an efficient way, but I feel it is hard to use. I don’t think a project which is already translated should receive new suggestions, unless a validator admin wanted to change things in the whole translation. I’d like to be able to make only the new strings available to receive suggestions. Last release we had a problem with a string which in older versions was correct and now it is wrong. I don’t know what happend but somewhere in the process somebody suggested a wrong translation to something that was already translated before and this new wrong translation got approved. I think GlotPress is too focused on making the process a mechanical thing, while there’s a long way to become a good translation tool. We have our own glossary and it would be awesome to be able to search the translation for inconsistencies and to integrate this glossary to it, rather them having google translator which is useless, (at least for us, the translations suggested are awfull). Other improvement it lacks is to show the same string just once with all the suggestions to it, rather them to multiply it for each suggestion. It just makes our work as validators a nightmare. I know I can see all the suggestions to a string, but I need to click on it. It’s not efficient. And I think this could end the problem of the augmentation of page number. As a validator, I’d like to have control of which strings shouldn’t receive suggestions anymore. I’d like to see better level of role and capabilities. I’d like to setup a team of trusted translators with permissions to discard suggestions, but not with permissions to approve. I’d like to have a comments area where translators could discuss the best suggestions, etc. So, I really think it’s easier to do all this with poedit. You’ll say that I can do that and just import the po to GlotPress, but it’s hard to maintain, I can’t control if somebodyelse will send another suggestion meanwhile and make me have to proof read again.
        So, I don’t know. I’m not very happy with it.

    • Akerbeltz 10:11 am on April 5, 2012 Permalink | Reply

      For my part, I *am* thrilled – I’m one of those people good at translating but pretty much useless at doing code and the less hair everyone uses having people like me blunder around in svn and suchlike, the better. I don’t see why it shouldn’t work, after all, projects like LibreOffice use such an approach for a very large number of languages too.

    • Naoko 5:19 am on April 11, 2012 Permalink | Reply

      Now that we (Japanese team) built 3.4 beta 1 package, I realized that the method using GlotPress is missing one important feature: specifying the POT version and corresponding translations.
      Currently GlotPress only tags version by 3.2.x, 3.3.x, and so on. This means there is no tags for beta, alpha, RC, and point-release versions for translation files.

      We have been manually creating PO/MO to make sure the original POT version is the latest one for the creation of each WP core tag. Else we could end up with discrepancies between the latest GlotPress strings and that of the package we are trying to build, depending on the timing of the build.

      • Andrew Nacin 3:44 pm on April 11, 2012 Permalink | Reply

        This is a good point, Naoko. I am wondering, though, do you foresee this affecting major and minor releases? We will move wp/dev to wp/3.4.x upon release, and were we to do another 3.3 minor release, wp/3.3.x would be current (we haven’t changed a string in a minor release in a while).

        So, I only see this affecting alpha, beta, and RC. In which case, I am wondering if it is necessary. For us, a beta or RC package is nothing more than a snapshot in time. There is nothing wrong with releasing r20426 (HEAD) rather than the exact revision for 3.4-beta1. Anyone updating using the beta testing plugin would also not be getting the exact revision; it goes through the separate nightly build process.

        I think it’s an interesting aspect, but I just don’t know how important it is. What do you think?

        • Xavier 9:16 am on April 12, 2012 Permalink | Reply

          Most excellent point from Naoko.

          I do think it is important for translators to be able to release test package based in any arbitrary revision, if only to be able to tell local trusted users to test a version before the final release. We’ve done that in the past on our blog: “Help us proofread the translation!”

          There used to be official POT files for beta and RC versions a long time ago (http://svn.automattic.com/wordpress-i18n/pot/tags/), but the tradition has been lost, so translators now have to hope that the POT they are translating against does indeed match the revision they are building their test archive against.

    • Lopo 2:27 am on June 1, 2012 Permalink | Reply

      I don’t know if you have this in mind but having a similar link to how support forums work today for plugins/themes would be great.

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

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

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

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

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

     

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

    I’ve updated the list of 3.4 changes:

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

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

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

     

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

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

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

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

      I can open a brand new ticket if need be.

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

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

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

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

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

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

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

     

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

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

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

     

  • Andrew Nacin 6:55 pm on January 27, 2012 Permalink | Reply
    nacin
    Tags: 3.4,   

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

     

← Older posts

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