Created attachment 4369 [details] A screenshot illustrating the problem When editing, with a plugin, a fixed length field of an existing (or new) record, some characters are changed when invoking the plugin (i.e. are not correctly passed to the plugin window). (The initial values for these fields set in .pl in variable $result are not respected as well). The attached screenshot illustrates the problem. This is because after switching to T::T variable names like: <!-- TMPL_IF name="f5|" --> or <!-- TMPL_IF name="f8 " --> (which were used in most of templates in /value_builder) are not allowed. In translation process these constructs have been replaced with [% IF ( f5pipe ) %] and [% IF ( f8 ) %] The corresponding *.pl files remain unchanged and provide the elements in the result hash as follows: my $f5 = substr( $result, 5, 1 ); [...] $template->param( [...] "f5$f5" => 1, So, if there is a pipe (or a space), the has key will be "f5|" ("f5 " resp.), which worked well with HTML::Template, but not with T::T. The same applies most probably to MARC-21.
Created attachment 4370 [details] [review] Proposed patch
The patch proposed make use of the idea of "f5pipe" in .tt files and adds also things like "f5space". (Sometimes it will be also dblpipe and dblspace.) Now a wrapper was needed in .pl to give the right things to the template param hash. The wrapper was added where needed. This id done for UNIMARC only. Most probably analogous things are to be done for MARC-21. Or perhaps anybody has a better idea...?
Created attachment 4371 [details] [review] Proposed patch There was a typo in previous version. Excuse me.
Created attachment 4374 [details] [review] Proposed patch (corrected) This is a corrected version of the patch. One has to pay attention if the $fx resulting from substr () is defined. In fact, it happens that if it comes from the end of the $result string and there were spaces at the end of the coded data, the spaces are cut off when passing the data from addbiblio dialog to the plugin. For instance if you have in you record: " d k y0frey50 " then you will get " d k y0frey50" in the plugin. So the test if $fx is defined in now being done.
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y Applying: Errata to Bugfix 6465 - Errors in UNIMARC plugins for fixed length fields (for | and space) (T::T issue) fatal: sha1 information is lacking or useless (cataloguing/value_builder/unimarc_field_100.pl). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Errata to Bugfix 6465 - Errors in UNIMARC plugins for fixed length fields (for | and space) (T::T issue)
Created attachment 4502 [details] [review] Proposed patch (corrected) Katrin, I am sorry for the trouble -- this is because I have generated the patch from my, slightly modified, version. Now it should apply smoothly, I hope.
I can confirm patch applies now to current master. I had problems reproducing the error, someone more familiar with UNIMARC should test this.
I met something odd and I don't know if it's a bug or not. In 100$a I have "19970701d1848 m y0frey50 ba" But for marked characters: ^^ I have "|- Filling character" in plugin. Is this a normal behaviour?
Julian, if I understand things well, what you are referring to has no relation to my patch nor with the problem described by me. The positions you are pointing at (i.e. 100/17-19) are Target Audience Code. According to my knowledge about field 100 (http://archive.ifla.org/VI/3/p1996-1/uni1.htm#100) spaces are not allowed there at all--one should choose from among [a b c d e k m u]. And "if some data in a field is supplied but not all, the omitted data element positions will contain fill characters" which is |. This is why having spaces in 100/17-19 you get | in the plugin, both having my patch applied or not. But if you wanted to see what I am referring to in my patch look at positions 17 and 18 in Unimarc record label for example, where spaces are allowed.
Ok, I finally understood the problem, and this patch fix it. Signed off. Something similar have to be done with marc21 plugins.
Corrects plugins to use 'wrapper' subroutine. Subroutine defined consistently on all plugins, and the necessary params are updated in the templates. Unfortunately, I am unfamiliar with UNIMARC, and cannot provide any feedback on the actual functionality of this patch. However, the code appears sounds. I'm trusting the signoff and marking as Passed QA.
As with Ian I am trusting that the UNIMARC functionality works ok, please test thoroughly. Scripts all pass syntax checks. Pushed
There have been no further reports of problems so I am marking this bug resolved.