Sounds like you've been hard at work and making great progress. It will
be great to have your dictionary, although there might be some new
strings to translate when GLI is next released.
> Thanks John, I could set the local language to the Greenstone interface, in few
>days we'll have completed this work (I will produce es_AR, from Argentina)
>dictionary, if anybody wants I could send.
> Also I could configure my Samba to using a remote Gatherer. The idea is in the
>server Greenstone folder I have two gli's folder, gli and gli2, only the server
>could use gli2 because Windows version tests if the folder is called gli. I have
>touched a litlle local setup.bat and few bat files. Everything looks working, I
>could connect the Windows gli to the Collection used in the server and
>automatically uploads the file. I only want that gli will be used from the
>Windows machine for Gathering and Enrinching the files (Around this I could set
>Preferences, but only remains for the session is there a way to save this
>preferences or should I touch the source code?).
In order to permanently hide a certain tab in GLI you must edit the
config.xml file found in the <greenstone_install>/gli/ folder. At or
around line 100 you'll see a block of Attribute statements all called
"workflow.something". If these are set to false they no longer appear in
the GUI and cannot be enabled, regardless of what collection is loaded.
In contrast changing the workflow settings through Preferences only
disables a certain pane (its still visible), and these settings belong
to the current collection.
> My doubt is around the lock file that Gatherer includes. Perhaps two operators
>will be working with the same collection using Gatherer, One only for
>adding/enriching files and the other for adding/enriching and building the
>entire collection. Is there any danger (supposing that the Linux operator will
>not re-build the collection when the other user is uploading or enriching?) with
>this schema?. The help says that is depending on who saves first. I assume that
>Gatherer will not present the "Refreshed" information to the two operators, but
>when the Linux user builds will build all the uploaded documents, isnt'it?
Unfortunately the lock file problem is a little more difficult to solve.
It is true that when a collection is loaded, it continually checks what
files are present in the collection, and so would remain up to date in
this regard no matter how many users are changing files. The problem
lies in the accompaning data files such as metadata.xml files. These are
loaded into memory when the collection is loaded, then written back out
when the collection is saved. Imagine if one user opened their
collection and started to enrich the documents, whereupon a second user
opened the collection then did some design. The first user saves their
collection, but when the second user saves it will overwrite the work
the first one just did.
The way we were planning to get around this was to save different parts
of the collection, depending on what 'views' were available. Thus a user
with collection/enrich would be able to save metadata.xml files, while a
user with design/create would only be able to save the collect.cfg file.
However the current GLI doesn't have this functionality, and I'm afraid
editing the source would be the easiest way for you to add it quickly.
You could also include information in the lock file about what parts of
the collection are already open, so that it would only appear it two
people tired to collect/enrich at the same time for instance. I'll add
this feature to our 'bug/requested features' list for you, but I don't
know how soon it will get dealt with.
> I'm looking now for other schema for working. I want a "production Collection"
>for all the people and other "in test". When operators end the testing phase
>will want to put the "test collection" into "production". I was thinking into
>put in the server another gsdl, perhaps in 8088 port (protected by Apache) and
>Gatherer connected to this through Connection Tab. Perhaps the following step
>will be to produce a script that moves files between the gsdl "sites". Do you
>see it possible?
As you suggest you can achieve this effect by setting the Library Path
in the connections tab of the Preferences dialog.
> One more thing, I could not find in the help the way that hierarchichal files
>are automatically produced, do you mean to import metadata from another files?
When you are entering a value for a certain piece of metadata you can
use the reserved character '\' (escape or back-slash) to seperate the
value into folders. So you could enter the values
"Cards\Red\Hearts\Seven" and "Cards\Red\Hearts\Ace", and you would
produce a hierarchy like so:
Where '+' denotes an expandable folder, and '-' a leaf value. When a
collection with assigned values, such as those shown above, is saved the
associated 'h-files' needed for the Hierarchy classifier to work are
Thanks for your input,
Greenstone Digital Library, University of Waikato,