Proposal: Pool of common strings for core, themes, and plugins
|Reported by:||demetris||Owned by:|
This idea originates in a little experiment I did during the 2.9 dev cycle. I wanted to see if it was possible to make a WordPress theme that would be not simply internationalized but also localized out of the box.
The method was simple:
If a string I needed existed in core, I left the second parameter of the gettext function empty, in order to use the default translation.
The result was better than I expected:
When I finished, I had a theme with a total of 100 strings, 70 of which were already localized out of the box!
I’ve thought a bit about the idea since and I believe it is worth pursuing because it will have significant benefits. However, before plugin/theme authors are willing to adopt the method, there are a couple of technical things we should do on our end. I’ll start with those, and then go on to enumerate the expected benefits.
- TECHNICAL PREREQUISITES
1.1. Central pool of common strings
Relying on core strings now is risky: Core strings can disappear or change at any time, leaving your plugin or theme partially localized.
A solution to this can be a file, say strings-common.php, that will contain core strings commonly needed by plugins or themes, and also strings not existing in core but commonly needed by plugins or themes. Strings in that file will not be removable, so that plugin/theme devs can use them safely.
Here is a small sample, to give you an idea of what kinds of strings I am talking about:
__('Next entries'); __('Next posts'); __('Permalink to %s'); __('Permanent link to %s'); __('Previous entries'); __('Previous posts'); __('Skip to content'); __('Skip to main content'); __('Valid CSS'); __('Valid CSS3'); __('Valid HTML'); __('Valid HTML5'); __('Valid XHTML');
1.2. POT-making script
As far as I know, there is no script now to make a plugin/theme POT that leaves out strings without text domain or with default as text domain. This would be essential for the idea to succeed. So, we would also need such a script.
2.1. Reduced workload for translators
This method of L10n/i18n will free up time for translators. Hopefully, part of that time will then go to more translations or to better translations, or to a bit of both.
2.2. Standardization and QA
For example, now all of the following are used:
- Changes saved
- Changes saved.
- Changes saved!
A strings-common.php file could standardize on one (the second one seems like the best candidate here) and thus encourage its usage.
Since a pool of common strings would be exposed to greater scrutiny, standardization and QA of this kind would also benefit core strings.
2.3. Performance and optimization
If this idea is promoted and widely adopted, it would result in lower memory usage for localized WordPress setups (memory usage is more of an issue in localized setups than it is in unlocalized setups).
It would also mean smaller packages for internationalized and localized themes and plugins.
- NOTES, CLARIFICATIONS
This method of L10n/i18n will of course be completely optional. If theme/plugin authors don’t like it, they don’t have to adopt it. If they don’t like the translation of a common string, or if they they want to use a common string within a context that changes its meaning, they can simply specify their own text domain for that common string.
I attach a file of common strings to which I add from time to time. It will give you a good idea of the extend of strings than are commonly needed in core, plugins, and themes.
What do you think?