This function reliably returns a useful value only on MacOS X. On Linux it's incorrectly determined by the
locale's encoding and on Windows it always returns 'mbcs' which is correct only on FAT file systems.
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
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: r21146
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
