Language attribute in DublinCore properties

I am using the OAI-PMH Repository plugin and I would like to include the xml:lang attribute in some of the fields. I have seen that Omeka S includes support for that, but I am not so sure about Omeka Classic (version 2.5.1). There is a Multilanguage plugin and a fork, but it seems more for offering translations to the users visiting the page rather than what I am looking for.

If there is no plugin for that, I could try writing one on my own and give it back to the Omeka community, though it could take some time due to my (un)availability and lack of knowledge about the Omeka structure. When doing this, I would still like to keep compatibility with the OAI-PMH Repository and Hide Elements plugins (in this second case, to hide some languages for human visitors, for instance).

If you are wondering what my use case is: I am part of a team managing an open journal targeting students and we would like to appear in a particular index, which requires being able to access the info via OAI-PMH and having the language attribute for fields like title, description and keywords. OJS might look like the natural software to use, but for various reasons we believe using Omeka (with some tweaks) can serve us better. Plus the mapping of items↔articles, collections↔issues/volumes (and maybe exhibits↔special classifications) seems to be good enough.

I’m not aware of a plugin that does specifically what you ask. But the good news is that it is specific enough that it might be easier to shove it into Omeka than a general language attribute.

I’d imagine that you’d need a table to store the lang values, and match those ids up with the values in the ElementText table. Then, for display, you’d do a query against those tables to filter out what you don’t want.

Hope that helps

That helps, thanks!

I’ll read the developer documentation to see how I should write the plugin. And if the lang values for the elements end up in core, I suppose it’ll be almost trivial to do the migration/update.

I’ll get back if I make it work or I’m stuck.

Right now, I have a table with columns id, element_text_id and lang (though element_text_id could be removed and add to id itself a foreign key constraint…):

CREATE TABLE IF NOT EXISTS `$db->ElementLangAttribute` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `element_text_id` int(10) unsigned NOT NULL,
  `lang` VARCHAR(20) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  KEY `lang` (`lang`),
  FOREIGN KEY (`element_text_id`) REFERENCES `$db->ElementText` (`id`)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

To add the field for the language in the item edit form, I am using the Element ElementInput Filter:

public function hookInitialize()
{
    add_filter(array('ElementInput', 'Item', 'Dublin Core', 'Description'), array($this, 'addLangAttributeToForm'));
}

public function addLangAttributeToForm($components, $args)
{
    $lang = strval($args['index']);
    $lang_field = get_view()->formText($args['input_name_stem'] . '[lang]', $lang, array('placeholder' => __("Language")));
    $components['input'] = $lang_field . $components['input'];
    return $components;
}

However, I have two issues. First, how can I save what is written on the Element[$id][$index][lang] field? In other plugins, I’ve seen that they extend Omeka_Controller_AbstractActionController, but that seems restricted to forms in new admin pages. Is the after_save_item hook the way to go? What fields does $args['post'] contain exactly?

The other issue: how can I prepopulate the new field in the input filter from the database? I know I get the corresponding Element object and index in $args, but I’m not sure if the element id and the index are enough to find the id for the corresponding ElementText object in the database. I mean, are the indices in the form in the same order as the ElementText ids in the database? Otherwise, what is the way to get the ElementText id given the Element id and form field index?

Thanks!

This topic was automatically closed after 250 days. New replies are no longer allowed.