Add items with IndependatBranches On was possibly get into trouble using a $0 value.
And frameworks used were those from itemtype instead of Bibliographic Record. May be considered as a feature provided that An itemtyp has only One framework attached.
* going back to a previous version, with server call to clone a Tag
* keeping BIG_LOOP in template (just 1 template for every tag)
I didn't check npl templates, but synch'ing them should not be too hard.
(ps : i've reverted default templates to 1.33.2.23)
when cloning a tag, there was a problem to detect the tag change when rebuilding the XML/MARC record :
the test was done on an empty field.
with the new CloneTag sub, this empty field was quite tricky to create on the fly.
so i've added on each subfield a <input name="firstsubfield"> saying wether the subfield is the 1st or not.
Thus, when a tag is cloned, it is cloned properly.
HTML2marc and well as HTML2xml have been modified, but PLEASE DOUBLE CHECK my work
2 things in this commit
- npl templates worked well for cloneSubfield, default one didn't. I couldn't understand why, so I ported npl template to default & just updated the stylesheet
- npl templates were awfully indented, so I indented them a little bit
- I thought for months that the idea of 10 tabs passed separately was crazy. So I fixed it : now there is just 1 (ONE) tab described in templates, that is looped by BIG_LOOP. The BIG_LOOP is filled by the build_tabs.
Works the same way as previously, except there is just 1 tab described in templates !!!
Things still to do :
- making cloneTag work correctly
- handle authorities popup, that is broken
- handle authorities reporting, that is broken too.
- ******** IMPORTANT *********
if TemplateEncoding system preference is set to iso8859-1, there are a lot of encoding problems : MARC::File::XML don't like it, as MARC::Record is supposed to work in MARC8 or UNICODE.
Thus, it seems that all accents are transformed in the process html => xml => marc.
Thus, i've reintroduced the html => marc behaviour if the TemplateEncoding is set to iso8859-1
(i've fixed the html2marc as joshua proposed previously, fixing a remaining bug)
This solution is a workaround : we will have to find a correct solution for Koha 3.0, to move every Koha to UNICODE and UNICODE only. But for instance, I tried some things but failed. Thust this solution, that works correctly for french libraries and should change nothing for unicode ones.
- z3950NormalizeAuthor of type YesNo. Set this to yes if you want author field to be filled with authorities fields when importing biblio in z3950
- z3950AuthorAuthfields, free text : type in comma-separated list of fields to search for author names for AuthorNormalization.
Adding a feature on a Z3950 import.
You can now automatically fill author with person name authority contained in the biblio if sysprefs are filled.
MARC::Record objects coming in from the reservoir are probably going to
be encoded as MARC-8. This enures that they will be converted into UTF-8
before being displayed to the user (if they are in fact MARC-8). It's most
easily done by turning the record into a MARC::File::XML object and then
going back to MARC::Record -- easiest to do for me that is. Of course, a
better solution is to create a routine that changes the encoding of a
MARC::Record object (I was surprised to find such did not exist). I have
tested this method for MARC21, but I'm not familiar with the issues with
encoding in UNIMARC: are UNIMARC records ever encoded in charater sets
other than MARC-8 and UTF-8? (if so, I will need to adjust this code).
Previous commits replaced the use of the MARChtml2marc
routine with a MARChtml2xml that reads in the form data and
converts it to a MARC::File::XML object. It then passes that
to MARC::Record via the new_from_xml() method.
This works perfectly and fixes all of the bugs with the old
MARChtml2marc routine (see mail to koha-devel). However,
there is one gotcha. The MARC::File::XML new_from_xml() method
converts UTF-8 data into MARC-8 by default for historical reasons.
This means that entry of characters outside the normal ascii range
in UTF-8 will come out as gibberish in MARC-8. Never fear, there
is a solution.
This commit uses code written for MARC::File::XML version 0.82 to
add the ability to specify the encoding desired (I chose UTF-8
because I can't think of a reason to ever need MARC-8)
The bottom line is that to properly encode records YOU WILL HAVE
TO UPDATE MARC::File::XML to at least CPAN verion 0.82 !!!!!
tipaul
hdl
kados
oleonard
tgarip1957