#Strings for translation: These need to be translated into French, Spanish, Russian, except where indicated. bibtext-e._text1_:Apart from the standard plugins, this collection uses BibTexPlugin, which processes references in the BibTeX format (well known to computer scientists). Two options have been set for BibTexPlugin: -OIDtype assigned -OIDmetadata Number. This means the metadata element \"Number\" will be used as the record identifier, instead of Greenstone's default hash identifiers. These options are available for all plugins.\n bibtext-e._text2_:This groups 200 documents together into a single archive file. bibtext-e._text3_:The buildtype option shows that the default search engine mgpp is used. The indexes line specifies indexes for \"text\", and \"metadata\". In this case, \"text\" will be the original BibTeX record. \"metadata\" is a special keyword signifying that an index should be built for any metadata item found in the collection. bibtex-3._text4_:An additional keyword, \"allfields\", could also be used in the indexers line, specifying that combined searching over all indexes should be available.

The levels lines specifies only document level, as bibliographic records don't have internal structure. #russian only bibtex-e._text5_:Fielded searching, with a form-based interface, is selected by format SearchTypes \"form,plain\" in the configuration file. In fact, a plain textual full-text search index is included in this collection as well (since form comes first, it is the default interface; you reach the plain search through the Preferences page).\n bibtex-supp-e._text1_:The \"documented-examples/\" parts of the collection names are necessary because these collections reside in the \"documented-examples\" collection group subfolder in the collect directory.\n wrdpdf-e._text1_:If you encounter these problems, you can either remove the offending documents from your collection, or try using some of the advanced plugin options to process the documents in different ways. For more information, see the Enhanced PDf and Word tutorials on the Greenstone wiki. # the following string has only changed a little, so have put the original strings hee too. isis-e._text1_:These databases have several files, but ISISPlugin uses just three: CDS.fdt (where CDS is the name of the database), containing the field names used in the database, CDF.xrf (a cross-reference file), and CDS.mst, containing the actual records. Whenever ISISPlugin encounters an \".mst\" file, it looks for the corresponding \".fdt\" and \".xrf\" files. isis-e._text1_ [l=fr] Ces bases de données ont plusieurs fichiers, mais ISISPlugin en utilise seulement deux: CDS.fdt (où CDS est le nom de la base de données) contenant les noms de champ utilisés dans la base de données, et CDS.mst qui contient les enregistrements. A chaque fois que ISISPlugin rencontre un fichier \".mst\", il cherche le fichier \".fdt\" correspondant. isis-e._text1_ [l=es] Estas bases de datos contienen varios archivos, pero ISISPlugin solo utiliza dos: CDS.fdt (donde CDS es el nombre de la base de datos), el cual contiene los nombres de los campos usados en la base de datos, y CDS.mst, el cual contiene los registros. Cada vez que ISISPlugin encuentra un archivo \".mst\", busca el archivo \".fdt\" correspondiente. isis-e._text1_ [l=ru] Эти базы данных состоят из нескольких файлов, но плагин ISISPlugin использует только два: CDS.fdt , (где CDS -- имя базы данных ), содержащий имена полей, используемых в базе данных, и CDS.mst, содержащий фактические записи. Всякий раз, когда ISISPlugin сталкивается с файлом \".mst\" он ищет для него соответствующий файл \".fdt\". isis-e._text2_:The -OIDtype incremental plugin option was used to give identifiers that are consistent across different operating systems (which may not happen with HASH identifiers), so that we can link to a document in this description. authen-e._text1_:The collection configuration file is exactly the same as for the original demo collection apart from the authentication directives, one plugin option (and this description). authen-e._text1_[l=fr] Ce fichier de configuration de collection est exactement le même que celui de la collection de démonstration originale sauf pour les directives d'authentification (et cette description). authen-e._text1_[l=es] El archivo de configuración es exactamente el mismo que el de la demo original salvo las directivas para la autenticación (y su descripción). authen-e._text1_[l=ru]Файл конфигурации коллекции точно такой же как и в оригинальной демо коллекции кроме директив аутентификации (и данного описания). authen-e._text2_:In this case, we have used the -OIDtype dirname option to HTMLPlugin, which specifies that directory names should be used as identifiers. This works for collections where each document is in a separate directory. We have used this option to ensure that identifiers remain the same across different platforms (which may not be the case for HASH identifiers), as we need to specify identifiers here for the authentication directives. #russian only dls-e._text1_:The DLS collection is fairly complex. dls-e._text2_:this text is part of it marc-e._text1_:The dc.Title classifier is an AZList, while the other two are AZCompactList, which groups items with the same metadata into a bookshelf. The -removesuffix argument for the Title and Creator classifiers removes suffixes from the metadata string (dc.Title and dc.Creator respectively). marc-e._text2_:The VList format statement controls the display of search results and all classifiers. For bookshelves, the number of leaf documents is displayed on the right-hand side. For documents, dc.Title is displayed, along with dc.Creator and dc.Publisher. [sibling:dc.Creator] is used as dc.Creator has multiple values, and specifies that all values be output, not just the first one. marc-e._text3_:Multiple MARC fields may map to a single Dublin Core field. For example, fields 720 (\"Uncontrolled name\"), 100 (\"Personal name\"), 110 (\"Corporate name\") and 111 (\"Meeting name\") all map to dc.Creator. Actual MARC records normally define only one of these fields, and anyway Greenstone allows multi-valued metadata.\n

Some mappings are dependent on subfields. For example, MARC field 260 contains information about publication and distribution. Subfields \"c\" (Date of Publication) and \"g\" (Date of manufacture) are mapped to dc.Date, using the following mapping line:

260$c$g -> dc.Date
Greenstone also provides a file for mapping MARC to qualified dublin core: greenstone/etc/marc2qdc.txt. This can be used by the MARC plugin by setting the -metadata_mapping_file option to \"marc2qdc.txt\". ##################### The entire description (and collection meta) needs translating into chinese and arabic if possible for all collections. pagedimg-e, style-e, wiki-e have no translations yet, so entire thing needs to be done for fr, es, ru. pagedimg-e has strings in extra.dm that need translating. the two strings in the top level (group) etc/collect.cfg also need translating. In particular to check translations: bibtex-e in russian. collections I have done (I think): authen-e bibtex-e & bibtex-supp-e garish-e image-e isis-e pagedimg-e style-e wiki-e wrdpdf-e marc-e don't send off the others yet!! I haven't checked all colls yet for search meta using _labeltext_. You probably won't have time either... ############################################################ Next installment: gsarch-e._text1_:This is a collection of email messages from the Greenstone mailing list archives, from November/December, 2008. gsarch-e._text2_:In this case, there is a file per month per mailing list, and each file contains many email messages. gsarch-e._text3_:The Email plugin splits these into individual documents, and produces Title, Subject, From, FromName, FromAddr, Date, DateText, InReplyTo, and optionally Headers, metadata. gsarch-e._text3_ [l=fr]Le plugin E-mail les éclate en documents individuels et produit les méta-données Title, Subject, Headers, From, FromName, FromAddr, Date et DateText. gsarch-e._text3_ [l=es] El plugin Email los divide en documentos individuales y produce metadatos de Título, Asunto, Encabezados, Remitente, Nombre del Remitente, Dirección del Remitente, Fecha y Texto de la Fecha (Title, Subject, Headers, From, FromName, FromAddr, Date y DateText, respectivamente). gsarch-e._text3_ [l=ru] Плагин Еmail разбивает их на индивидуальные документы и создает метаданные: Название (Title), Предмет (Subject), Заголовки (Headers), От (from), Имя отправителя (FromName), Адрес отправителя (FromAddr), Дата (Date) и DateText. gsarch-e._text4_:Otherwise the node\'s label starts with the Subject which links to the document, then gives FromName metadata, with a link to \"Search by Sender\", followed by the DateText. gsarch-e._text5_:For document nodes the FromName, with a link to \"Search By Sender\", Subject (linked to the document), and DateText metadata is shown. gsarch-e._text6_:Finally, the document text is formatted to show the header fields (FromName, DateText, Subject, InReplyTo), followed by the message text (written as [Text] in the format statement). FromName is linked to a search on that name, while InReplyTo links to the email message that it refers to. collections I have done: gsarch-e ## next installment dls._text3_:Note that setting \"public\" to \"false\" only removes it from the home page; it will still be accessible in the library to anyone that knows the URL (a=p&p=about&c=coll-shortname). dls._text4_:The \"plugin\" lines in the configuration file give the plugins used by the collection. dls._text4_ [l=fr] Le troisième bloc de lignes dans le fichier de configuration donne les plugins utilisés par cette collection. dls._text4_ [l=es] El tercer bloque de líneas en el archivo de configuración proporciona los plugins que usa esta colección. dls._text4_ [l=ru] Третий блок строк в конфигурационном файле представляет плагины, используемые коллекцией. dls._text5_: For example, this book has two dls.Subject classifications. dls._text6_:The second classifier provides access by title. It is also a Hierarchy classifier, this time based on dls.AZList metadata, whose hierarchy is defined in dls.AZList.txt. This file is discussed below. #russian only dls._text7_:The third provides access by organization: it is a List classifier based on dls.Organization metadata. dls._text8_:The -bookshelf_type always option creates a new bookshelf for each organization, even if only one document belongs to that category. dls._text9_:The fourth provides access by \"Howto\" text: it is a List classifier based on dls.Keyword metadata. The -bookshelf_type never option prevents bookshelves being created even if two documents share the same keywords. dls._text10_:The lines beginning with format, called \"format statements\", govern how various parts of the collection should be displayed. The VList format statement applies to lists of items displayed vertically, such as the lists of titles, subjects and organisations, and the table of contents for the target documents. It is overridden for the search results list by the SearchVList format statement, and also for the Howto classifier by the CL4VList statement (CL4 specifies the fourth classifier). dls._text11_:The DocumentText statement governs how the document text is formatted, with Title metadata ([Title]) in HTML <h3> format followed by the text of the document [Text]. Setting the DocumentImages format statement to true ensures that cover images are shown with each document. The DocumentButtons statement calls for the Expand Text, Expand Contents, Detach and Highlight buttons to be shown with each document. dls._text12_:Hierarchy files contain a succession of lines each of which has three items. The first item is a text string which is matched against the metadata that occurs in the metadata.xml file described above. The second item is a number that defines the position in the hierarchy. The third item is a text string that describes the node of the hierarchy on the web pages that Greenstone generates. dls._text13_:For example, the following shows three lines from the subject hierarchy file dls.Subject.txt. dls._text14_:These three lines define one top level bookshelf (at position 7), titled \"Animal Husbandry and Animal Product Processing\", with two bookshelves underneath it, titled \"Cattle\" and \"Other animals (micro-livestock, little known animals, silkworms, reptiles, frogs, snails, game, etc.)\" respectively. dls._text15_:In this case, the first strings (and therefore the entries in metadata.xml files) contain the entire hierarchy values. Levels in the hierarchy are separated by \"|\". They could be used directly by a Hierarchy classifier without the use of the hierarchy file. However, then the entries would be ordered alphabetically, not in the special order defined by the file. dls._text16_:The dls.AZList.txt hierarchy file used by the titles classifier contains a similar structure. Ordinarily, a titles browser would use a List (or AZList) classifier. In this case, we want to predefine the A-Z groupings, and include a separate entry for periodicals, as can be seen here. image-e._text1_:The images in this collection have been produced by members of the Department of Computer Science, University of Waikato. The University of Waikato holds copyright. They may be distributed freely, without any restrictions. oai._text1_:Besides the four standard plugins (GreenstoneXMLPlugin, MetadataXMLPlugin, ArchivesInfPlugin and DirectoryPlugin), the configuration file specifies the OAI plugin, which processes OAI metadata, and the image plugin, because in this case the collection\'s source documents are image files. oai._text2_:Extracted metadata from OAI records are mapped to Dublin Core Metadata Set by default. As a result, classifiers and indexes in this collection are built with Dublin meatadata elements. # for russian only, to check and update Можно удивляться, что AZCompactList используется вместо AZList также для индекса Описания (dc.Description), потому что метаданные Описания обычно уникальны для каждого изображения. Однако в данной коллекции одно и то же описание иногда давалось нескольким изображениям, и некоторые из разделов AZList содержат большое число изображений, замедляя передачу этой страницы. Чтобы избежать этого, используется компактная версия списка с рядом параметров (mincompact, maxcompact, mingroup, minnesting), чтобы управлять показом. Так, группы, представленные книжными полками, не сформируются до тех пор, пока они не будут иметь по крайней мере 5 элементов (mingroup). Чтобы узнать значения других параметров для этого классификатора, выполните команду classinfo.pl AZCompactList. Программы classinfo.pl (для классификаторов) и pluginfo.pl (для плагинов) являются полезными инструментами, когда надо узнать о возможностях модулей Greenstone. Обратите кстати внимание на обратный слеш в конфигурационном файле, используемый для указания на продолжение предыдущей строки.

oai._text3_:Greenstone's OAI server currently supports Dublin Core, qualified Dublin Core and rfc1807 metadata sets. The oaimetadata line specifies which sets should be used. For collections that use other metadata sets, metadata mapping rules should be provided to map the existing metadata to the sets in use. See the oai.cfg file for details.\n oai._text4_:The collection configuration file has a single full-text index containing dc.Description metadata. When a document is displayed, the DocumentHeading format statement puts out its dc.Subject. Then the DocumentText statement follows this with screenicon, which is produced by ImagePlugin and gives a screen-resolution version of the image; it is hyperlinked to the dc.OrigURL metadata -- that is, the original version of the image on the remote OAI site. This is followed by the image\'s dc.Description, also with a hyperlink; the image\'s size and type, again generated as metadata by ImagePlugin; and then dc.Subject, dc.Publisher, and dc.Rights metadata. This is the result.\n