Opened 15 years ago
Closed 11 years ago
#817 closed enhancement (no action required)
The default theme should have its own localization domain
| Reported by: |
|
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)
#3
@
14 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
@
14 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).
Likely the default theme strings will be separated in a future release.