in some cases produce empty PDF sheets or force graphviz to crash
Problem was due to calling localized float() when parsing a C-locale xml file
svn: r22706
PEP-0008 reserves the use of a trailing underscore for names
which conflict with Python keywords, which this doesn't.
The goal is to have a permanent name which is unique across
the gramps namespace, since it is defined (in po/genpot.sh
and po/update_po.py) as a keyword to flag strings to be put
into the translation "catalog" file (gramps.pot).
The new keyword "trans_text" is still unique. (Also "_T_".)
svn: r22200
'Foo has no attribute _Foo__get_type'
From moving the set_locale function to the superclass. One can get
carried away with enforcing private attributes...
svn: r22063
when failing to load an add-on translation
Message now says (e.g.) WARNING: Plugin ExtendedAttributes has no translation for any of your configured languages, using US English instead
svn: r22056
With GrampsLocale.float().
Also remove gen.plug.utils gformat(), which was written to work
around string formatting with %f localizing the decimal point,
which it doesn't do. locale.format() does, but it wasn't being
used anyway.
svn: r22045
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: r21985
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: r21983
Only get an addon translator if the plugin has a locale directory
Prevents pointless warnings, esp. when the translations are in the
main Gramps message file.
svn: r21649
from const.py to version.py
As noted in the previous change, importing const into setup.py tried to
initialize GrampsLocale and ResourcePath, which won't work. Since all we
want is the VERSION string, move that to a new file, gramps/version.py
svn: r21619
Making use of the fact that GrampsLocale now knows what
encoding to use, and noting that filesystems don't use
more than one encoding to write filenames in directories.
Also specify the encoding on some more files
svn: r21396
On MSWin and OSX, this call always returns the correct
value (utf-8 on OSX, 'mbcs' on MSWin), but on Linux the
return value is bizarrely dependent upon the environment.
Replace it with a GrampsLocale function which returns 'utf-8'
(the correct value for most Linux file systems) regardless of
the environment.
Also replace its use in print and write functions: It's the
encoding of paths in the filesystem, not of the files's content,
nor of the terminal's capabilities. The former is almost
always utf-8 as long as we write the file, the latter is
given by sys.stdout.encoding. Use the 'backslashreplace' error
handler to avoid exceptions when we need to output unicode
text to an ASCII terminal.
svn: r21394
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: r21391
maclocale.py
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: r21390
