We're updating the issue view to help you get more done. 

Import from CollectiveAccess do not take the locale that set in import settings

Description

Scenario:
1. Runing import from CollectiveAccess. in the import map set Setting locale en_US.
If there is no Preferred Label lang en_US in the source it is take the first data that came back.

2. Runing import from CollectiveAccess.
in the import map set Setting locale he_IL. The user interface locale is en_US.
It is take Preferred Label or attributes with lang en_US from source and add it as lang he_IL.

Where did it come from:
/app/lib/ca/Import/DataReaders/CollectiveAccessDataReader.php line 181
$ va_data ['attributes'] = caExtractValuesByUserLocale ($ va_data ['attributes']);
$ va_tmp = caExtractValuesByUserLocale (array ($ va_data ['preferred_labels']));

This should be taken get the data by the language that defined in the import settings and not by the user locale. If the source not in including data in the import language it should return Null

Environment

None

Activity

Show:
avihay halevi
April 11, 2018, 9:58 AM

at /app/models/ca_data_importers.php
pass $vn_locale_id to getValueFromSource function
at getValueFromSource pass it to $po_reader->get

at app/lib/ca/Import/DataReaders/CollectiveAccessDataReader.php get function
$va_data['attributes']
$va_data['preferred_labels']
Extract like that

function ExtractLocaleValues($locale, $pa_values){
if(!$locale || !$pa_values){
return null;
}
$vr_value=array();
foreach($pa_values as $pm_node => $vm_value) {
if (array_key_exists($locale, $vm_value)) {
$vr_value[$pm_node]= $vm_value[$locale];
}
else{
$vr_value[$pm_node]= array();
}
}
return $vr_value;
}

Orestes Sanchez
January 1, 2020, 11:50 PM

Same for me using a new `ca_ES` locale. I realized about it when importing dates in locale format.

I have found a way to solve it, by configuring the default language of the TimeExpressionParser, by using `g_ui_locale`.

Orestes Sanchez
January 2, 2020, 11:58 AM

The way over g_ui_locale was not the right one, it was using the UI locale, not the one on the import mapping. I have a workaround on this see PR at

The point is that I set the language on the TimeExpressionParser every time I have a value to insert, it doesn’t look too efficient

I think the proper way to solve it will be to make sure the static TimeExpressionParser at DateRangeAttributeValue is created with the right locale. In fact, it is not right the way it is, since the locale for each value of a DateRangeAttributeValue should be in different locales

Assignee

User known

Reporter

avihay halevi

Labels

Components

Affects versions

Priority

Major
Configure