On Wed, 2006-12-13 at 23:01 +0200, Eero Tamminen wrote:
> On Wednesday 13 December 2006 07:39, Alex Roitman wrote:
> > Both converting back and forth and storing two strings
> > is not a huge overhead at runtime. The real problem is,
> > gramps was not designed to keep displayable and
> > storable filenames separate from the real filenames.
> > There's simply too many places in the code where files
> > are accessed, their names stored, retrieved, etc.
> > So what seemed like an easy hack is a huge task.
> This is not only a problem in Gramps...
This is nice to know :-)
> > I am very tempted to just declare that we do not
> > support non-utf8 filenames. We can minimize the effect
> > on the user, e.g. when we get the non-utf filename
> > we can inform the user and suggest an alternative
> > filename.
> I think this sounds quite reasonable. Only old files with old filename=
> are a problem, everything new is using UTF-8.
> This is passing problem at least on Linux as Linux's free so there's no
> reason why people wouldn't upgrade (they cannot run newer Gramps on old
> distros :-)) but I think also Windows uses UTF-8. Older versions of Wind=
> could be a problem, but Gramps is not supporting Windows. ;-)
This sounds way better than I have anticipated :-)
I expected the uproar from the European users demanding
to support every encoding.
Before we commit to these steps, does everybody on this list
share this view? Does everybody agree that this is a passing
problem and that the new files need to use UTF-8 anyway?
If not, how are the other applications coping up with this?
Alexander Roitman http://www.gramps-project.org