Skip to:
Content

Opened 16 months ago

Closed 7 months ago

Last modified 3 months ago

#5621 closed task (fixed)

Remove buddypress.pot from develop repo

Reported by: netweb Owned by: boonebgorges
Milestone: 2.3 Priority: high
Severity: normal Version:
Component: Locale Keywords: early has-patch
Cc:

Description

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. :)

Attachments (4)

5160-makepot.diff (444.3 KB) - added by netweb 16 months ago.
Migrated original patch via #5160
5621.diff (531 bytes) - added by netweb 16 months ago.
5621.2.diff (614 bytes) - added by netweb 16 months ago.
5621.3.diff (205.3 KB) - added by netweb 7 months ago.

Download all attachments as: .zip

Change History (39)

@netweb16 months ago

Migrated original patch via #5160

@netweb16 months ago

@netweb16 months ago

comment:1 in reply to: ↑ description @netweb16 months ago

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

comment:2 @johnjamesjacoby16 months ago

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.

comment:3 @DJPaul16 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 2.1

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.

comment:4 @netweb16 months ago

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:

comment:5 follow-up: @boonebgorges16 months ago

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.

comment:6 in reply to: ↑ 5 @netweb16 months ago

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)

comment:7 @ircbot16 months ago

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges_. View the logs.

comment:8 @ircbot15 months ago

This ticket was mentioned in IRC in #buddypress-dev by netweb. View the logs.

comment:9 follow-up: @johnjamesjacoby15 months ago

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.

comment:10 @johnjamesjacoby15 months ago

In 8469:

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

comment:11 @DJPaul15 months ago

  • Resolution set to fixed
  • Status changed from new to closed

comment:12 in reply to: ↑ 9 @netweb13 months ago

  • Priority changed from normal to high
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:13 @DJPaul13 months ago

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

comment:14 @ircbot13 months ago

This ticket was mentioned in IRC in #buddypress-dev by paulgibbs. View the logs.

comment:15 follow-ups: @nacin13 months ago

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?

comment:16 in reply to: ↑ 15 @netweb13 months ago

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

comment:17 @netweb13 months ago

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

comment:18 in reply to: ↑ 15 @DJPaul13 months ago

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. :)

comment:19 @netweb12 months ago

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.

comment:20 @nacin12 months ago

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.

comment:21 @nacin12 months ago

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.

comment:22 @nacin12 months ago

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:

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.

comment:23 @boonebgorges12 months ago

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.

comment:24 @DJPaul11 months ago

  • Milestone changed from 2.1 to 2.2

comment:25 @boonebgorges11 months ago

  • Owner set to boonebgorges
  • Status changed from reopened to assigned

Closed #5920 as a duplicate.

comment:26 @johnjamesjacoby7 months ago

  • Component changed from Component - Core to Locale
  • Keywords early added; needs-patch removed
  • Milestone changed from 2.2 to 2.3
  • Type changed from enhancement to task

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

comment:27 @netweb7 months ago

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:

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.

comment:28 follow-up: @johnjamesjacoby7 months ago

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.

@netweb7 months ago

comment:29 in reply to: ↑ 28 @netweb7 months ago

  • Keywords has-patch added

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)

comment:30 follow-up: @johnjamesjacoby7 months ago

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

comment:31 in reply to: ↑ 30 @netweb7 months ago

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/

comment:32 @johnjamesjacoby7 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

comment:33 @slackbot7 months ago

This ticket was mentioned in Slack in #meta-i18n by netweb. View the logs.

comment:34 @slackbot5 months ago

This ticket was mentioned in Slack in #buddypress by netweb. View the logs.

comment:35 @slackbot3 months ago

This ticket was mentioned in Slack in #meta-i18n by netweb. View the logs.

Note: See TracTickets for help on using tickets.