L10n/i18n updates.
Superfluous whitespace removed.
Add FIXME for a few i18n issues I couldn't solve this quickly.
Takes care of documentation for all core code added in merge of "people tags" feature (Commit:e75c9988ebe33822e493ac225859bc593ff9b855).
$config['site']['logperf'] = true; // to record & dump total hits of each type and the runtime to syslog
$config['site']['logperf_detail'] = true; // very verbose -- dump the individual cache keys and queries as they get used (may contain private info in some queries)
Seeing 180 cache gets on a timeline page seems not unusual currently; since these run in serial, even relatively small roundtrip times can add up heavily.
We should consider ways to reduce the number of round trips, such as more frequently storing compound objects or the output of processing in memcached.
Doing parallel multi-key lookups could also help by collapsing round-trip times, but might not be easy to fit into SN's object model. (For things like streams this should actually work pretty well -- grab the list, then when it's returned go grab all the individual items in parallel and return the list)
We can make a lot of HTTP requests from the server side. This change
adds some configuration options for using an HTTP proxy, which can
cache hits from multiple sites (good for status.net-like services, for example).
If a cache entry is dependent on the code that's running, upgrading
(or enabling/disabling plugins) can generate hard-to-track
inconsistencies.
This change adds a close-to-unique fingerprint of the running code to
some cache keys, so that if the fingerprint changes, the old values
are ignored and new values are used.
If the automated uniqueness fails, an administrator can add an extra
config value, $config['site']['build'], that's thrown into the key also.
If a cache entry is dependent on the code that's running, upgrading
(or enabling/disabling plugins) can generate hard-to-track
inconsistencies.
This change adds a close-to-unique fingerprint of the running code to
some cache keys, so that if the fingerprint changes, the old values
are ignored and new values are used.
If the automated uniqueness fails, an administrator can add an extra
config value, $config['site']['build'], that's thrown into the key also.
This option may be useful for intranet sites that don't have direct access to the internet, as they may be unable to successfully fetch those resources.
This will apply to *ALL* plugins in *ALL* languages, so should probably only be used when doing site customization...
You'd probably do:
$config['site']['locale_path'] = '/srv/awesome/data/locale';
$config['plugins']['locale_path'] = '/srv/awesome/data/locale';
with a structure like:
srv/
awesome/
data/
locale/
en/
LC_MESSAGES/
statusnet.po
OpenID.po
AnonymousFave.po
etc, all alongside each other. You could separate plugins from the core if you like.
Where locale files have not already been generated, you can build one for a plugin like so:
php scripts/update_po_templates.php --plugin=MyPlugin
and pull out the template file:
plugins/MyPlugin/locale/MyPlugin.pot
Edit that (make sure you at least set the CHARSET, probably to UTF-8) and save your customized .po
files into the structure as above, and use msgfmt to generate .mo files for final output.
