EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #04379
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
[EP-tech] Re: [spam?] Re: How to set a field to be multilang
- To: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
- Subject: [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- From: Timothy Miles-Board <timothy.miles-board@ulcc.ac.uk>
- Date: Thu, 25 Jun 2015 08:42:41 +0000
The "problem" is that when you ask $eprint->get_value() for the value of a multilang field it gives you a perl data structure - in this case arrayref (array of {langcode=>text} hashrefs) - ie. the same behaviour as you would expect for a compound field or any field with a multiple value.
$eprint->get_value() is used everywhere - including in export plugins. So any field where the plugin implicitly expects a string - like title, abstract etc - it will output something like ARRAYx01123123
So your options are:
* Fix up all the plugins to be cleverer about how they get the "best" value of multilang field (ie. use get_value() then look at the user's lang / default lang to pull out the best string from the multilang structure) - but this would mean repeating the same routine in every plugin..
* Change the way that get_value() works so that it somehow decides which behaviour to use (arrayref vs best lang string) based on calling context etc. - get_value is used everywhere in EPrints so this would probably break everything..
* Add a layer of abstraction between the low level get_value() and the plugins that defines an API for returning language dependent strings - then change all the plugins to use that (so instead of get_value(), plugins could call get_lang_string() or something - something like this would be the best approach...
In the meantime, what you could do is instead of changing the default title, abstract etc fields, just define new multilang versions.
So eg. ml_title, ml_abstract ...
Then use these in your workflow instead of the default title, abstract .. etc.
Finally in eprint_fields_automatic.pl, write some code to take the ml_* fields and populate the equivalent scalar fields. So eg. get the value of ml_title, pull out the text in the default language (or if the default language version is not defined, some other language in order of preference - the EPrints::Language module already does stuff like this with phrases) and write that value into the title field.
Then anything that expects $eprint->get_value( "title" ) to return a string will be happy (albeit they will always give the default/preferred language).
Or...
Change the default title, abstract etc. fields to a virtual field so that you can dynamically work out the (string) value by looking at ml_title, ml_abstract etc - as long as the value returned is always a string this shouldn't break anything.
Food for thought I hope,
Tim
Timothy Miles-Board
Web & Repositories Development Specialist, University of London Computer Centre 020 7863 1342 | 07742 970 351 | timothy.miles-board@london.ac.uk | @drtjmb The University of London is an exempt charity in England and Wales From: eprints-tech-bounces@ecs.soton.ac.uk <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of George Mamalakis <mamalos@eng.auth.gr>
Sent: 25 June 2015 8:38 AM To: eprints-tech@ecs.soton.ac.uk Subject: [EP-tech] Re: [spam?] Re: How to set a field to be multilang Thanks Alen, I'll look into it deeper.
It's sad, though, that default Import/Export plugins break. Could you give a few hints on how to customise these plugins? (general guidelines). Could the changes be applied on the parent Import and Export plugin, or most child plugins tend to override functions dealing with title, abstract, etc? And that being the case, isn't it equivalent to adding extra fields for an additional language? Either way same things are broken, right? :) Lastly, where are these metadata fields stored in the database? Reading the article in the link you provided diagonally, it seems that I need to update the database in order to create them, right? Thanks again! On 24/06/2015 11:18 μμ, Alen Vodopijevec wrote: Hi! -- George Mamalakis IT and Security Officer, Electrical and Computer Engineer (Aristotle Univ. of Thessaloniki), PhD (Aristotle Univ. of Thessaloniki), MSc (Imperial College of London) School of Electrical and Computer Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 |
- References:
- [EP-tech] Re: How to set a field to be multilang
- From: Timothy Miles-Board <timothy.miles-board@ulcc.ac.uk>
- [EP-tech] Re: How to set a field to be multilang
- From: George Mamalakis <mamalos@eng.auth.gr>
- [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- From: Alen Vodopijevec <alen@irb.hr>
- [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- From: George Mamalakis <mamalos@eng.auth.gr>
- [EP-tech] Re: How to set a field to be multilang
- Prev by Date: [EP-tech] Re: EPrints ACL's status (EPACL or alternatives)
- Next by Date: [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- Previous by thread: [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- Next by thread: [EP-tech] Re: [spam?] Re: How to set a field to be multilang
- Index(es):