Remove buddypress.pot from develop repo

[netweb]

via DJPaul ticket:5160#comment49
5160-makepot.diff

• AFAIK, we haven't turned off potbot yet.
• We shouldn't remove the bp-languages folder until that's done, because otherwise it might break things.
• bp_core_load_buddypress_textdomain() also needs updating.
• I don't think generating the POT on every main Grunt task is a good idea, because it's not very fast -- plus those changes aren't included in this patch?
• Switching the CWD from SOURCE to BUILD will cause trunk to not contain any POT file which will break * GlotPress (the build folder is not being added to trunk).
• From this patch, I think the idea to update the headers and move the POT to the root of src is great. * Everything else, not so sure yet. :)

[netweb]

Migrated original patch via #5160

[netweb]

Original patch copied over for reference only: 5160-makepot.diff​

Replying to DJPaul ticket:5160#comment49

5160-makepot.diff

• AFAIK, we haven't turned off potbot yet.
• We shouldn't remove the bp-languages folder until that's done, because otherwise it might break things.
• bp_core_load_buddypress_textdomain() also needs updating.
• I don't think generating the POT on every main Grunt task is a good idea, because it's not very fast -- plus those changes aren't included in this patch?
• Switching the CWD from SOURCE to BUILD will cause trunk to not contain any POT file which will break
  • GlotPress (the build folder is not being added to trunk).
• From this patch, I think the idea to update the headers and move the POT to the root of src is great.
  • Everything else, not so sure yet. :)

• Agreed, it's not that fast, it was already in the grunt build-commit and therefore grunt build-release tasks, probably not needed in the default grunt build task.

• Correct, /src will no longer contain a buddypress.pot. GlotPress

• AFAIK GlotPress grabs the .pot file from WP's plugin repo (​here) and not BP's Trac,though I'm not 100% sure on this and indeed could be wrong.

• I personally haven't taken a look at bp_core_load_buddypress_textdomain

In 5621.2.diff just the 'pot header' and location are updated.

• ToDo SVN move and retain history for buddypress.pot
  • From \src\bp-languages\
  • To \
  • Remove the \src\bp-languages\ folder

[johnjamesjacoby]

Lots of talking points here, and I'll do my best to clarify them:

• As a sister project, our .pot is currently taken from buddypress.svn.wordpress.org. We can change this, and I don't see any obvious reason not to. It would allow us to control the flow of language changes a bit, since we'd point it to plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot which we use for periodic pre-release pushes, deploys to buddypress.org, etc...
• I think we'll still want to keep the .pot file at the root of the /src/ directory, so it's included in the zip. We don't want it in the root of /trunk since that's only used for the bootstrapping and grunt running processes.
• I'm not super concerned about retaining the .pot history. It's hardly human readable, and GlotPress already maintains a historical record of translations for releases. That said, it's easy enough to copy over, so we may as well.
• Creating the .pot maybe adds an extra second or two to something that used to take several minutes of manually moving around. I see no reason to let a few extra seconds be the reason we're not moving forward on including this.

[DJPaul]

My "I don't think generating the POT on every main Grunt task is a good idea, because it's not very fast" comment here copied from the other ticket appears a little out of context on this ticket. It's also a bit irrelevant, and to clarify, already our pre-commit Grunt script runs makepot, so we're already updating the file when we need to, so it's no extra work.

John's other point about perhaps using wp-plugins.svn as a source for GlotPress' buddypress.pot, I don't really have an opinion on, but perhaps we should ask some of the translators whether they'd prefer to translate a whole bunch of new phrases once we get to alpha/beta/release, or whether the current "trickle" of new translations is preferable.

[netweb]

Paul, my bad, sorry, I did not mean take this out of context and tried to keep the context :(

Translators do not typically keep all the GlotPress projects at 100% so 95%+ would not notice. Give the ​Make Polyglots blog a heads up when a new release is near/pending/live and they will jump on in.

My recommendation:

• Point GlotPress to plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot
• Remove buddypress.pot entirely from the buddypress.trac.wordpress.org repo

In doing the above:

• Then there is no requirement to have the Grunt task makepot as part of either the grunt build or grunt build-commit tasks, it only needs to be in the grunt build-release task when used to push an update to plugins.svn.wordpress.org/buddypress/trunk for periodic updates for translators, 'alpha/beta' /trunk testers or deployment to buddypress.org.
• The buddypress.pot would be included in .zip download via any 'wordpress.org' BP download locations:
  • ​http://downloads.wordpress.org/plugin/buddypress.2.0.1.zip
  • ​http://downloads.wordpress.org/plugin/buddypress.zip

[boonebgorges]

I don't think generating the POT on every main Grunt task is a good idea, because it's not very fast

Takes one or two seconds on my machines. This doesn't seem like a deciding factor in either direction.

On balance, netweb's suggestions seem right to me. I don't see much benefit in including the .pot in our development branch. It kinda messes with changelogs. The people most likely to be affected are those who like to run trunk in a live environment in language other than English. They would need to write a script to periodically grab the latest from plugins.svn.wordpress.org. (Translators themselves are not using our svn repo anyway.)

This move adds a bit of overhead for the BP core team. We have to come up with a system for periodically ensuring that plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot is bumped up to date. That said, we should talk to translators. If it turns out that most wait until beta anyway, then maybe we don't need any separate periodic syncs.

[netweb]

Replying to boonebgorges:

On balance, netweb's suggestions seem right to me. I don't see much benefit in including the .pot in our development branch. It kinda messes with changelogs. The people most likely to be affected are those who like to run trunk in a live environment in language other than English. They would need to write a script to periodically grab the latest from plugins.svn.wordpress.org. (Translators themselves are not using our svn repo anyway.)

Not so, since I created the Australian Translation of WordPress, BuddyPress and bbPress around half of my installs are set to en_AU. Not having the .pot file is not an issue, we don't need the .pot file.

Also now that automatic translations are flowing via automatic updates (Woot @nacin) (some tweaks are needed when running on /trunk for the /dev translations) things are pretty good in this area and will only get better.

If an issue does arise I will be certain to raise it.

This move adds a bit of overhead for the BP core team. We have to come up with a system for periodically ensuring that plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot is bumped up to date. That said, we should talk to translators. If it turns out that most wait until beta anyway, then maybe we don't need any separate periodic syncs.

Taking one overhead away (no need to commit the .pot by devs) and 'maybe' adding another, wouldn't/shouldn't this already be a task for BP dev's anyway for those running /trunk via the plugins.svn.wordpress.org repo?
(Like bbPress stats on the amount of people running /trunk from either repo I have no idea)

I haven't dug through the available GitHub hooks available to be used though if there is one to available (or a Trac SVN plugin) there might be a way to automate this if the Travis build passes then publish to /trunk on the plugins repo. I can't see a way to do this directly with Travis CI without comprising BP's security credentials for plugins.svn.wordpress.org repo.

A side benefit of the en_AU translation is I keep en_AU pretty much at 100% for all the GlotPress projects, I will typically once a week drop by to update any translations, apart from us Aussies the Korean translation team is the only other who are keeping frequent translation updates, though I am not forgetting fr_FR for BuddyPress.
(kind of broad generalisations/assumptions here but I do notice who is/isn't keeping /dev branches up to date)

[johnjamesjacoby]

In 8468:

Translation Updates:

• Remove bp-languages directory and buddypress.pot from src directory.
• Move buddypress.pot into root of build directory.
• Update Gruntfile.js to only run makepot task when building a new release.
• We'll need to update GlotPress to point to the plugins.svn.wordpress.org repository later.

Props netweb. See #5621.

[johnjamesjacoby]

In 8469:

Add makepot to build-release Grunt task. Props netweb. See #5621.

[netweb]

Replying to johnjamesjacoby:

• We'll need to update GlotPress to point to the plugins.svn.wordpress.org repository later.

This still hasn't been done yet and why the ticket (from memory) was not resolved as fixed at the time.

Translators have not had any new strings in the /dev branch to translate since r8468 when buddypress.pot was removed from the repo.

[DJPaul]

We'll need to talk to nacin for help with this.

[nacin]

The preferred course of action would be for me to transition from parsing buddypress.svn.wordpress.org for strings to extracting strings from plugins.svn.wordpress.org/buddypress. This makes sense as all plugins will be moving in that direction anyway. However this means that at the very least, trunk must be pushed to plugins.svn at the time of betas/RCs to ensure that translators have strings before major releases.

Sound good?

[netweb]

Replying to nacin:

The preferred course of action would be for me to transition from parsing buddypress.svn.wordpress.org for strings to extracting strings from plugins.svn.wordpress.org/buddypress. This makes sense as all plugins will be moving in that direction anyway. However this means that at the very least, trunk must be pushed to plugins.svn at the time of betas/RCs to ensure that translators have strings before major releases.

Sound good?

If via some "black box" magic we can run our grunt build-release task from /trunk here on buddypress.svn to automatically deploy to plugins.svn /trunk when a commit is made (similar in how each commit here is pushed to the BuddyPress GitHub mirror) the bb's would then via plugins.svn /trunk have a 'release' build similar to how core.svn works for WordPress Core develop.svn repo.

I have no idea if any of the above is possible, nor if said 'black box' exists, nor if said 'black box' is what pushes the commits to the BuddyPress GitHub mirror, it would be cool though :)

If the above is not possibile then going for what you outlined above is fine by me, @JJJ and @DJPaul agreed the same via ​IRC this morning:

jjj: I'd rather we point glotpress to plugins.svn, and manage the push to glotpress when we're ready.
paulgibbs: ok, agreed

[netweb]

Related: #5813 potbot goes wild adding buddypress.pot to every branch and tag here on buddypress.svn

[DJPaul]

Replying to nacin:

The preferred course of action would be for me to transition from parsing buddypress.svn.wordpress.org for strings to extracting strings from plugins.svn.wordpress.org/buddypress.

Sound good?

This is 100% exactly what the core team would like done, please. :)

[netweb]

bbPress is now automagically updating strings with the latest strings without a bbpress.pot file in plugins.svn or bbpress.svn. I'm presuming @Nacin has performed some 'black box' magic which is very cool and many thanks.

Not sure why BuddyPress is not yet doing this, or if it has only been setup for bbPress thus far.

The ​string mentioned in IRC last week "No new topic tags to convert" via ​bbPress:changeset:5454 has now arrived in GlotPress, I also committed ​bbPress:changeset:5456 to confirm string changes are arriving.

Related: ​#GlotPress348 needs further investigation, plugin Name, description and author strings are not translated.

[nacin]

bbpress.pot ends up in ​http://bbpress-i18n.svn.wordpress.org/pot/, which is an otherwise dead repo. We could do the same in ​http://i18n.svn.buddypress.org/ (and also otherwise dead repo) but this uses the core i18n tools, not the grunt task.

[nacin]

BuddyPress doesn't have branches synced to ​https://plugins.svn.wordpress.org/buddypress/. So I'm having it check buddypress.svn first, and if the file doesn't exist there, then it'll pull from plugins.svn. buddypress/dev is now synced (and will remain synced) here: ​http://translate.wordpress.org/projects/buddypress/dev.

Wehn 2.1 is about to come out, please let me know so I can have language packs built. (This is still manual for the moment while we work out kinks.) Then we'll do the GlotPress branching juggle so 2.2-alpha/trunk is reflected in dev.

[nacin]

A note, ​http://translate.wordpress.org/projects/buddypress/dev is pulling from ​https://plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot. At the moment, however, these two files are the same:

• ​https://plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot
• ​https://buddypress.svn.wordpress.org/branches/2.0/buddypress.pot

If you want to populate /dev with new strings, then update the pot in plugins.svn. The script to pull this runs at :59 every hour.

[boonebgorges]

Thanks, nacin - this looks about perfect. One question:

I'm having it check buddypress.svn first, and if the file doesn't exist there, then it'll pull from plugins.svn

Does this go for trunk too, or just the branches? If so, I'll probably remove buddypress.pot altogether from plugins.svn.wordpress.org, so that everything gets pulled from buddypress.svn.

[boonebgorges]

Closed #5920 as a duplicate.

[johnjamesjacoby]

Moving to 2.3 early, so we can figure this out for realsies.

[netweb]

Here's what happened with the release of BP 2.2:

I thought at the time of release a handful of locales were 100% translated, turns out they weren't as buddypress.pot had not been updated for ~9 days, the final 26 strings only became available for translation once BP 2.2 was released.

GlotPress /dev strings are taken from ​https://plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot per Nacin's ​comment above and buddypress.pot was only updated as part of the BP 2.2 release:

• "Update BuddyPress trunk to 2.2.0. Stable tag bumped to 2.2.0. The galaxy is at peace."
• ​https://plugins.trac.wordpress.org/browser/buddypress/trunk/buddypress.pot?rev=1082686
• buddypress.pot log ​https://plugins.trac.wordpress.org/log/buddypress/trunk/buddypress.pot

If GlotPress strings are to remain being pulled from the current location then BuddyPress needs to update this more frequently as release time nears, it is also nice to not have a glut of new strings turn up when translating so as frequently as possible is the best outcome for the #polyglots translations teams.

[johnjamesjacoby]

That's helpful. Based on the numerous fragmented threads, this wasn't clear to anyone that discussed it before tagging 2.2.

This means we are free to remove buddypress.pot from BuddyPress.svn and will only need to push to plugins.svn when we choose. I am perfectly fine with this arrangement as it gives us the opportunity to do an actual string freeze by choice.

[netweb]

Replying to johnjamesjacoby:

This means we are free to remove buddypress.pot from BuddyPress.svn and will only need to push to plugins.svn when we choose. I am perfectly fine with this arrangement as it gives us the opportunity to do an actual string freeze by choice.

Correct.

Running grunt release and pushing to https://plugins.svn.wordpress.org/browser/buddypress/trunk/ will make new strings available to translators via GlotPress.

Patch 5621.3.diff removes buddypress.pot from /trunk of buddypress.svn.wordpress.org repo
(Hmmm patch looks weird, svn del buddypress.pot should achieve the required result)

[johnjamesjacoby]

Thanks netweb. Would you want to add updating the .pot file to our launch checklist on the codex? :D

[netweb]

Replying to johnjamesjacoby:

Thanks netweb. Would you want to add updating the .pot file to our launch checklist on the codex? :D

Done (or at least 1st draft) ​https://codex.buddypress.org/prelaunch-checklist/

[johnjamesjacoby]

In 9449:

Delete buddypress.pot from repository root.

For GlotPress going forward, we will be using: plugins.svn.wordpress.org/buddypress/trunk/buddypress.pot

This brings BuddyPress up to speed with what other plugins will likely be expected to do for WordPress.org-wide localization.

Fixes #5621. Hat-tip netweb.