Description of issue
I am experiencing an issue with the Data Importer in Providence 2.0 where list items created via listItemSplitter are consistently assigned to the en_US locale, despite explicit mapping configurations to use ca_ES.
System Environment:
- CollectiveAccess Version: 2.0
- Locale for import:
ca_ES (Locale ID 14 in ca_locales)
- Database check: [ca_ES](https://) is present in the database, enabled, and
dont_use_for_cataloguing is set to 0.
Mapping Configuration:
I am using the following configuration to split a semicolon-separated string and map it to a List attribute (rendered as a Checklist):
- Refinery:
listItemSplitter
- Refinery Parameters:
{"list": "mfa_tecnica", "separator": ";", "matchOn": ["label"], "attributes": {"locale": "ca_ES"}}
- Options:
{"delimiter": ";", "locale": "ca_ES"}
(The delimeter parameter is used to separate items on the import_data colum.)
The Issue:
- The separation of values works correctly due to the
delimiter in the Options column.
- However, when the importer creates a new list item that doesn't already exist, it ignores the
locale parameter in both the Refinery Parameters and the Row Options.
- The new items are always created with
en_US labels.
- I have tried using both the string
"ca_ES" and the integer ID 14 in the parameters, with no success.
Expected Behavior:
The listItemSplitter should respect the locale attribute provided in the parameters or the row options when creating new ca_list_items and their correspondingpreferred_labels.
Steps taken to troubleshoot:
- Verified that
ca_ES is a valid cataloguing locale.
- Tested with and without
matchOn.
- Tested forcing the locale ID directly in the JSON.
- Cleaned application cache between imports.
Additional Context:
It is important to note that the {"locale": "ca_ES"} option works perfectly when mapping directly to ca_objects.preferred_labels or other primary object attributes. The issue is strictly isolated to when a Refinery (listItemSplitter) is used to create related entities. In those cases, the locale context from the "Options" column (or the refinery parameters) seems to get lost or ignored, reverting the created list items to the system default (en_US).
Any guidance on whether this is a known bug in the 2.0 importer or if there is a specific configuration in app.conf or setup.php that might be overriding the mapping's locale would be appreciated.
Thanks.
