Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 8 years ago

#817 closed enhancement (no action required)

The default theme should have its own localization domain

Reported by: mark-k Owned by:
Milestone: Priority: minor
Severity: normal Version:
Component: Core Keywords:
Cc:

Description

as the .mo file of the buddypress plugin is loaded on every page load, it would be nice to reduce it size in order to reduce its memory and cpu (at parsing time) footprint.

Ideally there would be a per page localization, but that is not realistic in any sane way. What it is realistic, and it is something that wordpress is doing wrong, is to separate between the core localization and the theme localization.

At the way things are currently being done, even if I use my own theme which do not use localization api at all, I still get penalized from having the default theme localization part of the whole buddypress localization embedded in the .mo file.

IMHO, with buddypress themes being installed outside of the plugin directory structure, it even makes more sense to have a separate and independent localization for the default theme.

Change History (6)

#1 @apeatling
12 years ago

  • Milestone set to Future Release

Likely the default theme strings will be separated in a future release.

#2 @DJPaul
12 years ago

  • Milestone changed from Future Release to 1.3

#3 @boonebgorges
11 years ago

  • Component set to Core

+1 on the general idea.

A couple thoughts:
1) Is there any way to do this and maintain some sort of backward compatibility? As it stands, anyone with a custom language pack is going to have half of their translations wiped out once this move is made. I'm thinking the answer is "no", but maybe someone with a better sense of the mechanics of gettext can chime in.
2) We'll have to coordinate with whoever runs the potbot to make sure that we transition smoothly to a two-pot situation

Can anyone wager whether we'll have dev time for this for 1.3?

#4 @DJPaul
11 years ago

I don't know of any backwards compatible way of doing this without duplicating the strings and writing some fallback code (i.e. gettext would potentially use twice the memory).

#5 @DJPaul
11 years ago

  • Milestone changed from 1.3 to Future Release

Changing milestone to future release as I think it is best addressed as, when and if we replace/update BP-Default with a totally new theme.

#6 @boonebgorges
8 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Severity set to normal
  • Status changed from new to closed

Now that BP is designed to be compatible with any WordPress theme, I don't think the issue is really relevant anymore. Closing this ticket.

Note: See TracTickets for help on using tickets.