[Koha] Trying to use a template in Batch record modification
Alvaro Cornejo
cornejo.alvaro at gmail.com
Tue Mar 19 07:32:29 NZDT 2019
Hi Michael
> How about changing a record with already with ger to any other
> language?
I don't know exactly what you mean. Editing the record manually from
"ger" to any other MARC language code is no problem....
I mean you can try to use the batch record modification tool to change the
"ger to "abc" for example and see if it does do the change as opposite of
as when you "add" ger. With this we can test if it behaves differently
between those cases and might give us a clue.
In the test I'll use a language code that you do not use or does not exist
so you can then easy spot those records and return the language code back
to "ger" easily
Regards,
Alvaro
|-----------------------------------------------------------------------------------------------------------------|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS
y GPRS online
Visitenos en www.perusms.com
Le lun. 18 mars 2019 à 13:22, Alvaro Cornejo <cornejo.alvaro at gmail.com> a
écrit :
> Hi Michael
>
> Another way would be to access mysql directly and do the replacement there.
>
> You can build a report for records that are missing the "ger" and with
> that build a replace query to add the "ger" in the location you need.
>
> Regards,
>
>
> |-----------------------------------------------------------------------------------------------------------------|
> Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
> celular y Nextel
> en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS
> y GPRS online
> Visitenos en www.perusms.com
>
>
> Le lun. 18 mars 2019 à 11:26, Michael Kuhn <mik at adminkuhn.ch> a écrit :
>
>> Hi Alvaro
>>
>> You wrote:
>>
>> > Have you tried manual edit of the field and see how it shows
>> > before/after the modification in opac/staff and mark view?
>>
>> Editing the record field manually is no problem (here from "ger" to
>> "fre" in MARC 008,35-37). Before it looks like
>>
>> 800422s1978 sz a 1 ger
>>
>> And after the action like this:
>>
>> 800422s1978 sz a 1 fre
>>
>> MARC 008 definitely MUST have 40 characters (position 0-39) but as seen
>> in the above example here only 23 characters are shown since the
>> webbrowser collapses several blanks down to one blank, according to some
>> weird HTML rule. So this is wrong in all the MARC views, OPAC or staff
>> client, I think not only in the current but in all previous versions,
>> thus kind of a bug.
>>
>> For this problem see https://www.w3schools.com/html/html_entities.asp
>> where they write:
>>
>> "If you write 10 spaces in your text, the browser will remove 9 of them.
>> To add real spaces to your text, you can use the character entity."
>>
>> But Koha doesn't add any so the correct number of characters is
>> destroyed in the webbroweser.
>>
>> > Also in your regex, "ger" is case sensitive. Might you have "Ger"?
>> > Have you tried a case insensitive for regex "ger"?
>>
>> No, I always have "ger" since it is the correct MARC language code for
>> German.
>>
>> > How about changing a record with already with ger to any other
>> > language?
>>
>> I don't know exactly what you mean. Editing the record manually from
>> "ger" to any other MARC language code is no problem. Using the MARC
>> modification templates to change MARC 008,35-37 seems not possible since
>> this feature seems only to be able to handle data fields but not the
>> special structure of controlfields (or, however, I didn't find out how
>> to achieve this - but anyway it is not what I want to do).
>>
>>
>> In my case I just defined the following template action which I was able
>> to save, but when applying it to an appropriate record, nothing happens
>> and no new MARC 041$ager is added. Why does this not work?
>>
>> Add new field 041$a with value ger if 008 matches RegEx
>> m/^...................................ger..$/
>>
>> Is there maybe another way to add MARC 041$ager to every record that has
>> "ger" in MARC 008,35-37?
>>
>> Best wishes: Michael
>> --
>> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch · W www.adminkuhn.ch
>>
>>
>>
>>
>> > Le dim. 17 mars 2019 à 09:21, Michael Kuhn <mik at adminkuhn.ch
>> > <mailto:mik at adminkuhn.ch>> a écrit :
>> >
>> > Hi Jonathan
>> >
>> > You wrote:
>> >
>> > > For kidding I wanted to answer you that dots were missing.
>> > > But actually:
>> > > % echo '...................................'|wc -m # number of
>> dots
>> > before ger
>> > > 36
>> > > % echo '190315b ||||| |||| 00| 0 '|wc -m # all chars before ger
>> > > 26
>> >
>> > In fact the MARC view in the staff client and the OPAC do not show
>> the
>> > correct content (as foudn in the database) of any field, if mor than
>> > one
>> > blnak does appear fllowing each other - instead the they will be
>> > automatically collapsed down by the webbrowser to just one. Even the
>> > MARC plain view in the OPAC behaves in this wrong way; and only (but
>> > most importantly) the actual catalogueing framework behaves
>> correctly.
>> >
>> > So the OPAC view etc will show something like the following, which
>> > according to the MARC 21 format can never be correct because MARC
>> 008
>> > MUST contain 40 characters, but the OPAC view does only show 31 in
>> this
>> > case:
>> >
>> > 190315b ||||| |||| 00| 0 ger d
>> >
>> > However, of course I hope the Batch record modification will work on
>> > the
>> > actual data in the database which of course actually does contain
>> > exactly 40 characters: (I kept the tags to show where the data
>> actually
>> > begins and ends, since blanks are hardly visible)
>> >
>> > <controlfield tag="008">800422s1978 sz a 1 ger
>> > </controlfield>
>> >
>> > > Maybe there are too many?
>> >
>> > No, I have counted them before, my regular expression looks like
>> >
>> > m/^...................................ger..$/
>> >
>> > According to the MARC 21 Format for Bibliographic Data controlfield
>> 008
>> > contains 40 positions. In my regular expression
>> >
>> > * positions 0-34 can contain any character (thus 35 dots)
>> >
>> > * positions 35-37 must contain "ger" (thus the three characters
>> "ger")
>> >
>> > * positions 38-39 can contain any character (thus 2 dots).
>> >
>> > All in all my expressions does contain 40 positions. So I guess it
>> > should work, but it doesn't. Is this maybe a bug?
>> >
>> > Best wishes: Michael
>> > --
>> > Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg.
>> Fachausweis
>> > Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>> > T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch
>> > <mailto:mik at adminkuhn.ch> · W www.adminkuhn.ch <
>> http://www.adminkuhn.ch>
>> >
>> >
>> >
>> > > Le ven. 15 mars 2019 à 15:42, Michael Kuhn <mik at adminkuhn.ch
>> > <mailto:mik at adminkuhn.ch>> a écrit :
>> > >>
>> > >> Hi
>> > >>
>> > >> Currently some Koha newbies have forgotten to add the value
>> "ger" in
>> > >> MARC 041$a when catalogueing, but they did add the correct value
>> > "ger"
>> > >> in MARC 008,35-37. However, this results in some missing entries
>> > in the
>> > >> language facet. The plain MARC view in the OPAC of such a
>> record may
>> > >> look like this:
>> > >>
>> > >> 000 00216nam a22001097a 4500
>> > >> 999 _c470
>> > >> _d470
>> > >> 003 OSt
>> > >> 005 20190315191317.0
>> > >> 008 190315b ||||| |||| 00| 0 ger d
>> > >> 040 _cOSt
>> > >> 245 _aTest
>> > >> 942 _2z
>> > >> _cBK
>> > >>
>> > >> In fact it is missing
>> > >>
>> > >> 041 _ager
>> > >>
>> > >> Thus I tried using the MARC modification templates in Koha menu
>> > "Tools >
>> > >> Batch record modification", adding a template with the following
>> > action
>> > >> (as copied from the interface):
>> > >>
>> > >> Add new field 041$a with value ger if 008 matches RegEx
>> > >> m/^...................................ger..$/
>> > >>
>> > >> When I run this action over the given record, Koha tells me
>> that the
>> > >> bibliographic record has successfully been modified - but in
>> fact
>> > >> nothing has changed.
>> > >>
>> > >> Besides it is not possible to unload that record using "Data
>> > export",
>> > >> but it is there an can be searched via staff client and OPAC.
>> > >>
>> > >> What is wrong with my evil doing? Is it something with my
>> regular
>> > >> expression?
>> > >>
>> > >> Best wishes: Michael
>> > >> --
>> > >> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg.
>> > Fachausweis
>> > >> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>> > >> T 0041 (0)61 261 55 61 · E mik at adminkuhn.ch
>> > <mailto:mik at adminkuhn.ch> · W www.adminkuhn.ch <
>> http://www.adminkuhn.ch>
>> > _______________________________________________
>> > Koha mailing list http://koha-community.org
>> > Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>> > https://lists.katipo.co.nz/mailman/listinfo/koha
>> >
>>
>>
>>
More information about the Koha
mailing list