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.
Cátia Kitahara, 
Gabriel Reguly 5:29 pm on April 4, 2012 Permalink |
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.
Andrew Nacin 5:30 pm on April 4, 2012 Permalink |
Could you describe what about it was not working well? If this has to do with continents-cities, I fixed that this morning. Anything else, and I’d like to know.
Gabriel Reguly 5:45 pm on April 4, 2012 Permalink |
Oh boy, sorry but I don’t recall what was the issue.
Is it possible to make a build now without breaking the existing releases?
Andrew Nacin 5:53 pm on April 4, 2012 Permalink |
Yes, you can make “Builds” any time you’d like. Just be careful what you “Release.”
Gabriel Reguly 5:53 pm on April 4, 2012 Permalink |
Ok, did a little research of my old posts:
There was a javascript bug, please see http://wppolyglots.wordpress.com/2011/12/08/a-few-string-changes/#comment-6159
Themes were losing translations, please see https://wppolyglots.wordpress.com/2011/07/13/twenty-eleven-losses-translation-after-3-2-1-update/#comment-3597
Andrew Nacin 5:55 pm on April 4, 2012 Permalink |
The JavaScript bug should be fixed.
The theme translations issue is a core thing, not a GlotPress vs SVN thing.
Gabriel Reguly 5:56 pm on April 4, 2012 Permalink
But if one uses SVN, then the themes do get their translations. At least for the release.
Andrew Nacin 6:02 pm on April 4, 2012 Permalink
We’ll work on that for 3.4.
Andrew Nacin 6:06 pm on April 4, 2012 Permalink
I tested this some more, and could not reproduce. A build from GlotPress adds the proper language files in place.
The issue highlighted in the thread linked above is a different one, and has to do with someone updating Twenty Ten or Twenty Eleven from the directory. Different issue.
Gabriel Reguly 6:36 pm on April 4, 2012 Permalink
Again, thanks for our time.
Gabriel Reguly 5:58 pm on April 4, 2012 Permalink
Anyway, thanks for your time and patience with me.
Xavier 10:44 pm on April 4, 2012 Permalink |
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 |
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 |
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 |
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 |
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 |
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 |
Just tried to build a package with the new changes http://wppolyglots.wordpress.com/important-changes-for-wordpress-3-4/ not working…
Andrew Nacin 1:47 am on April 5, 2012 Permalink
Sorry, that’s a 3.4 change. (Won’t work for SVN builds either.) I’ll fix it tonight.
Andrew Nacin 4:38 pm on April 5, 2012 Permalink
This is unrelated to GlotPress.
Here, you removed dist/wp-content/languages/sv_SE.php: http://i18n.trac.wordpress.org/changeset/19072/sv_SE/trunk/dist.
That was prior to me going in and creating at 3.3 branch for you: http://i18n.trac.wordpress.org/changeset/19147/sv_SE/branches/3.3.
If you want to build a 3.3 release, you are going to need to re-add sv_SE.php to branches/3.3.
Come 3.4, you will not need to specify a $wp_default_secret_key so you were correct in removing the file.
I will fix the error message.
Andrew Nacin 4:39 pm on April 5, 2012 Permalink
(I created 3.4-beta1 sv_SE build using translate.wordpress.org and everything worked like a charm.)
Mattias Tengblad 4:57 pm on April 5, 2012 Permalink
I’m still getting the error trying to build a 3.4-beta1
Mattias Tengblad 5:01 pm on April 5, 2012 Permalink
Seems to have been a cached message
Andrew Nacin 5:02 pm on April 5, 2012 Permalink
That was my bad — I was testing off development code rather than production. Just deployed it.
Mattias Tengblad 5:04 pm on April 5, 2012 Permalink
Ah ok
Mattias Tengblad 1:56 am on April 5, 2012 Permalink |
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
Loading a GP page no longer takes ages: http://wppolyglots.wordpress.com/2012/04/05/i-added-persistent-caching-to-translate-wordpress-org/.
Cátia Kitahara 7:10 pm on June 20, 2012 Permalink |
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.
Mattias Tengblad 1:40 pm on June 21, 2012 Permalink |
+1
Akerbeltz 10:11 am on April 5, 2012 Permalink |
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 |
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 |
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 |
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.
Mattias Tengblad 12:17 pm on April 12, 2012 Permalink |
We do the same thing at the Swedish portal.
Lopo 2:27 am on June 1, 2012 Permalink |
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.