Hi Vitor,

The authorities.pref becomes bad-formatted after your patch (tabulations characters).

and in C4/AuthoritiesMarc.pm:
- The patch introduces a forbidden pattern: tabulation character (709)
- The patch introduces a forbidden pattern: withespace character  (709)

Hi Jonathan Druart,

The format problem maybe happen from copying from my pref test to the authorities.pref.
Can you test now?

I've modified the authorithies.pref.

Hi
In biblio records, field 100 is filled by a "plugin".
Is it possible to make plugins for authorities ? It could be usefull for other coded fields in authorities frameworks (ex : 106, 120, 123...)


Regards,
M. Saby
Rennes 2 University

Hi Mathieu,

This problem is different than the non existence of plugin to UNIMARC authorities.
This problem happens when creating/editing UNIMARC authorities where the cataloguing language is always set to 'fre'.
The submitted patch correct this problem by adding a system preference.

To UNIMARC Authority field 100 plugin there is another bug open (BUG 8334).

(In reply to comment #4)
> Hi Jonathan Druart,
>
> The format problem maybe happen from copying from my pref test to the
> authorities.pref.
> Can you test now?
>
> I've modified the authorithies.pref.

Yes, it fixes the previous issue.

However I don't understand how to have a record without 100$a before entering in the AddAuthority routine.
In C4/AuthoritiesMarc ~l.710
We always enter in the following statement:
    if (my $string=$record->subfield('100',"a"))
and never in the elsif ($record->field('100')) or else statement.

Could you provide a test plan to test your patch please ?

Hi Jonathan,

When you put a correct 100$a there isn't any problem with the language, because it will use the language inserted in the subfield.

The problem happens when you insert or import a record without a field 100. The default language will be the 'fre' language.

The patch tries to correct that.

Yes, it is what I understood :)
When I add a new authority without 100$a and I edit it, I see the value '20121205     50                    '
and not what I put in the syspref.

Hi Jonathan,

The problem is that in authorities.pl the field 100 was filled with '20121205     50 ' if there wasn't a field 100.
That code should be removed because the field 100 verification should be in the AuthoritiesMarc.pm.

Squashed and signed-off patch.

Another SO would be great.

QA comment: in bibliographic frameworks, each subfield can have a default value (and date is automatically replaced if you usea YYYYMMDD pattern)
I had preferred that you introduced this feature for authorities instead of doing this patch only for the 100$a field. The improvement would have been much larger.

Would you be willing to rewrite your patch ?

(not changing the status, adding RM to this bug, so he can confirm he agrees with me or no)

Hi Paul,

I understand what you are saying.
Default values for authorities frameworks will be a nice improvement.
Besides that even with default values this patch is needed.
The field 100 in UNIMARC authorities always needed to be filled (using or not the interface). If the field isn't filled in the interface it will be automatically filled with the 'afrey50      ba0', which is a problem. This patch avoid that. With the patch 3 things happens:

- If the 100$a is filled nothing is done, so using default values or filling with plugins or by hand is not a problem
- If there is a 100 field but not a $a subfield, a 100$a is created with the date and the system preference created
- If there isn't a 100 field, a 100 field and a 100$a subfield are created with the date and the system preference created.

Even with default values the patch is needed, because 100$a needs to exist in UNIMARC even when is not filled in the interface.
There is another system preference that does something like this: MARCAuthorityControlField008

Paul,

(In reply to comment #14)
> QA comment: in bibliographic frameworks, each subfield can have a default
> value (and date is automatically replaced if you usea YYYYMMDD pattern)
> I had preferred that you introduced this feature for authorities instead of
> doing this patch only for the 100$a field. The improvement would have been
> much larger.
> 
> Would you be willing to rewrite your patch ?
> 
> (not changing the status, adding RM to this bug, so he can confirm he agrees
> with me or no)

This patch would be required anyway, I think, because right now the UNIMARC 100 field is forcefully populated to the hard-coded frey50:
jcamins@kohadev:~/kohaclone$ grep frey C4/*
C4/AuthoritiesMarc.pm:          $string=~s/fre50/frey50/;
C4/AuthoritiesMarc.pm:          $record->field('100')->update('a'=>$date."afrey50      ba0");
C4/AuthoritiesMarc.pm:            ,'a'=>$date."afrey50      ba0")
C4/Biblio.pm:        substr( $string, 22, 6, "frey50" );
C4/Charset.pm:        substr( $string, $encodingposition, 8, "frey50  " );

Hi Jared,

This patch is only for AuthoritiesMarc.pm.
There is another patch for BUG 8347, that changes Charset.pm and Biblio.pm.

OK, I agree with you arguments and change my mind. Will QA this patch later. If someone else want to QA, feel free.

Created attachment 15482 [details] [review]
[PASSED QA] BUG 9145: Authorities: standard language for UNIMARC

New Authority system preference created UNIMARCAuthorityField100 with default value "afrey50      ba0".
AuthoritiesMarc.pm uses the system preference instead of label "afrey50      ba0".

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, all tests and QA script pass.

1) Check system preference is created correctly.
2) Change pref.
3) Catalog a new authority.
4) Change framework to make 100 show in frameworks or check in the
   the database, that now 100 has the new defined value.

This patch has been pushed to master.

Pushed to 3.10.x will be in 3.10.3