Only one base translation per locale. To set up a different locale
on any axis (locale, domain, directory, or languages) instantiate a
secondary locale by calling GrampsLocale() with the appropriate
arguments.
svn: r21968
set_translation() to the Report class
Add a new module stdoptions to gen.plug.report with function
add_localization_option(). The intent of stdoptions is to reduce the code-copying among reports; this is the first bit.
svn: r21966
With GrampsLocale.sort_key (for strxfrm and conv*_tosrtkey) and
GrampsLocale.strcoll.
If ICU is available will use the correct ICU::Collator for the locale,
otherwise falls back to locale.strxfrm -- for which it temporarily
changes the LC_COLLATE locale.
svn: r21275
Permits sorting by localized language name.
Also hides the language code, which the user doesn't really care about.
Removes get_language_string from libtranslate.py, no longer needed.
svn: r21236
GrampsLocale is effectively a singleton: An instance is created in
const.py and retrieved everywhere.
Translations are provided via Translations classes, which are derived
from GNUTranslations and NullTranslations to provide extra functions
like sgettext.
svn: r21143
Reflecting discussion on gramps-devel about their affecting more than
just translations.
Provide for a master GrampsLocale instance to be retrieved from
const.py, set by grampsapp.
svn: r21142
round 2 for python 3 support:
* no more cmp, also not in sort and sorted
* bsddb needs bytestring keys
* gtk does not need utf-8 encoded anymore...
svn: r20658
This does patch updates Gramps to the 3.2 syntax, it does not yet mean Gramps works with python 3.2
Expect next day commits to fix further issues, but this is the main 2to3 tool created patch changed
where needed to have python 2.7 work.
Specific issues might be:
1. next has been changed, must be checked
2. new division as on the wiki page listed is to do
3. ...
svn: r20634
* somewhere along the road, all of plugins dir was added to sys.path, this
is not ok, we only needed lib on sys.path
* As due to the GEP we can import from the plugin directory, better just
import the lib modules needed, and avoid sys.path extension
* At the same time this fixes a bug due to __init__.py being present, import
of a file named equal to the plugin directory was importing the __init__.py,
not the intended file.
svn: r20481
