Bug #13047

Alternative identifier types/labels can't be translated

Added by Dan Gillean about 2 years ago. Updated about 1 year ago.

Status:NewStart date:05/23/2019
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:I18NEstimated time:90.00 hours
Target version:-
Google Code Legacy ID: Tested version:2.5, 2.6
Sponsored:No Requires documentation:

Description

Currently, alternative identifiers can't be translated.

The mapping is defined here: https://github.com/artefactual/atom/blob/HEAD/plugins/arElasticSearchPlugin/config/mapping.yml#L518-L522

these are being stored as key/value pairs in AtoM's property tables. Currently in AtoM's data model, the value (in this case the identifier) can technically be translated (as it is stored in property_i18n.value) but the label/type (stored as property.name) cannot - and that's the field we actually need to translate. In any case, currently neither field is translatable in AtoM's user interface.

In the ES index, these fields are also still accessed with:

alternativeIdentifiers.identifier
alternativeIdentifiers.label

The fact that these aren't nested in i18n suggests that they are not in fact properly indexed as translatable i18n fields in the database or index. A quick test confirms this - it looks like the fix for #9154 did not make the field translatable, it just made sure that existing alternative identifiers will use culture fallback and be visible when the user interface is flipped to a different culture.

To reproduce

  • Navigate to an existing description in English
  • Enter edit mode and add an alternative identifier. Save
  • Flip the user interface to another culture (e.g. French)
  • Re-enter edit mode

Error encountered

  • No ability to add translations for alternative identifiers

Expected result

  • Alternative identifiers labels can be translated

I get that for most cases, ID values don't need translation - however at minimum users should be able to translate the field labels.


Related issues

Related to Access to Memory (AtoM) - Bug #9154: Alternative identifier labels do not display when interfa... Verified 11/17/2015

History

#1 Updated by Dan Gillean about 2 years ago

  • Related to Bug #9154: Alternative identifier labels do not display when interface culture is flipped added

#3 Updated by Dan Gillean about 2 years ago

  • Assignee set to José Raddaoui Marín

#5 Updated by David Juhasz about 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from José Raddaoui Marín to Dan Gillean
  • Estimated time set to 16.00

Dan, I'd estimate 8 hrs each for development on Issues #1 and #2 - so two support tickets each. You may want to add some extra time if there are new documentation updates that require new screenshots or anything of the sort.

#6 Updated by David Juhasz about 2 years ago

  • Estimated time changed from 16.00 to 20.00

I'm adding 4 hours to the estimate for analysis, deployment and management.

#8 Updated by David Juhasz over 1 year ago

David Juhasz wrote:

Dan, I'd estimate 8 hrs each for development on Issues #1 and #2 - so two support tickets each. You may want to add some extra time if there are new documentation updates that require new screenshots or anything of the sort.

Issue #2 is actually more difficult than I thought, as it requires translating the alt identifier "label" not the value. The labels are currently stored in the property.name field, which doesn't exist in the property_i18n table. Being able to translate labels will require changing the data mapping for alt identifiers, which is a bigger job than I was thinking about when I estimated 2 support tickets.

#9 Updated by David Juhasz over 1 year ago

The best way I can think of to support translation of alternative identifier labels and values, without changing the database schema is:

  1. Make an alternative identifier taxonomy
  2. Make each alternative identifier type a term in the taxonomy (`term_i18n.value` = alt. id label)
  3. To add an alt id value to a an information object use a relation row (relation.subject_id = information_object.id, relation.object_id = term.id)
  4. Store the alt id value in a `relation_i18n.description` row.

#11 Updated by Dan Gillean over 1 year ago

  • Subject changed from Alternative identifier values are not tokenized in the search index, and can't be translated to Alternative identifier types/labels can't be translated
  • Description updated (diff)
  • Estimated time deleted (20.00)
  • Tested version 2.6 added

I have updated this issue - previously it described 2 problems, one of which has now been resolved in the 2.5 release. At present, alternative identifier labels still cannot be translated however. Also removing the previous estimate since further analysis has revealed that the problem is much more complex than originally thought.

As noted in the comments above, the preferred long-term strategy is to manage the labels in a new Taxonomy, called "Alternative identifier types" or similar. That way, the label field on the description would be an autocomplete populated from the taxonomy, a​llowing users to consistently re-use the same type without misspellings, minor variations, punctuation differences, typos, etc. Additionally, users can translate the label value in the taxonomy, rather than on the description. This could mean, when the same type is used many times, only having to make one edit to add a translation, rather than dozens or hundreds.

The Artefactual team has roughly ballparked the work required in the $10K USD range, as of 2019-09-26.

#12 Updated by Dan Gillean about 1 year ago

  • Status changed from Feedback to New
  • Assignee deleted (Dan Gillean)
  • Estimated time set to 90.00

#13 Updated by Dan Gillean about 1 year ago

  • Category changed from Information object to I18N

Also available in: Atom PDF