[sword-devel] Sword for BPBible 1.5.12

[Manfred Bergmann]

Am 07.04.2009 um 08:45 schrieb Matthew Talbert:

>> The fact remains that old locale files and new locale files cannot  
>> operate
>> on the same sword configuration.  Both 1.5.x and 1.6.x will fail if  
>> this is
>> the case.  We can make 1.6.x ignore the 1.5.x locales, but we can't  
>> do
>> anything about the 1.5.x software already on the computer.  It will  
>> cease to
>> work.  The correct thing to do is to not mix locale formats on the  
>> same
>> sword configuration.  I can't see how passing hard coded paths is a  
>> better
>> solution.
>
> This bothers me as well. I don't have a solution, but I know that it
> is impossible for us to know during installation where the user's
> locales.d actually is. I'm thinking in particular of users that
> specify SWORD_PATH as being somewhere other than the default. If we
> can't tell for sure where they are during installation, then we can't
> overwrite or remove the old ones, so we really don't have control over
> what is going to happen when the user starts up the front-end. As I
> said, I don't really have a solution, but it would seem that locales.d
> should be handled a little differently than SWORD_PATH. Specifying a
> path for LocaleMgr would probably work, though I haven't really
> thought about it.

We're specifying a path for LocalMgr in MacSword in form of:
sword::LocaleMgr *lManager = sword::LocaleMgr::getSystemLocaleMgr();
lManager->loadConfigDir([localePath UTF8String]);

We have to since Mac OSX doesn't have a package management system as  
part of the OS.
So we can't and won't tell the user to install (or even compile) the  
Sword library as a dependency for MacSword.
That's why we deliver the complete library including locales.d within  
the Application bundle.



Manfred