Pyxform v2.0.0 shows error `Text is not localizable for default locale` for form using search() and a localized CSV

Hello Community.
I am having errors when I upload an XLSForm on ODK Central. This issue only happened when our ODK Central was upgraded to the latest version. Docker version 24.0.5, build ced0996 and Docker Compose version v2.20.2
When I upload an XLSForm that requires the use of pull CSV data, I get an error ': Item '${id_}:label': text is not localizable for default locale [Portuguese (pt)]!.
I have tried rewriting the name and using different XLSForm with different pull CSV data but I get a similar error with the unique IDs in the pull data
I am stacked. I need assistance to continue.
Thank you

1 Like

Can you please share a copy of your form?

Also, can you specify the version of Central you are running? To see your version, click on the question mark icon in the upper right section of your Central menu bar, then click Version. If you don't see the question mark, you can see the version by adding version.txt to the root URL (e.g.,

Hello @yanokwa
Thanks for the response.
The versions are:
ed8817cd84eab2f3f448f4e7f254c8f435571c49 (v2023.5.0-4-ged8817c)
ab0c8ecbf837c7e433b20c7d7d1d2955cc8df1c6 client (v2023.5.0)
983ec81e69793fdb589ffdc346a16ef977489be4 server (v2023.5.0)

I have also atta
V2_Form 3c Distribuição de Inputs.xlsx (59.1 KB)
ched the form.

Thanks for reporting this. It's related to this form conversion change and its interaction with the search() appearance/function with multi-language forms. Here's the issue which we'll try to address soon:

We should continue to generate an inline select in this special case ...

(Why?) How can we then implement it with instance() it for Enketo, please, as the search isn't available there?

We have now merged and released a fix which you can verify at We'll release a new version of Central with this fix shortly.

We really try hard to maintain compatibility where possible, even for features like search() that aren't included in the primary ODK documentation.

The approach for building selects from CSVs that works in Collect and Enketo is select_one_from_file, possibly with a choice filter, and customizing the label and value if you don't want to use name and label columns.

There is not yet a way to specify localized columns. We have a proposal at Proposal: customize name and label 'columns' in selects from external data in XLSForm - #9 by martijnr but it did not get a lot of interest and we have not yet had a chance to prioritize it.

1 Like

Sorry, "Why?" was related to your solution approach in github; "generate an inline select in this special case". Could your standard solution to use secondary instance(s), which "can be filtered and queried", not be an advantage here too (esp. for future development).

I see, good question. That change would have to be made in Collect. There are a few reasons we wanted to approach it in pyxform instead:

  • it's harder for a project to control Collect versions used. If we made this change in Collect, affected users would have to ensure that all their data collectors upgraded or they'd get a confusing crash.
  • the search() code has almost no automated tests around it so it's more risky and time-consuming to work in. We generally consider it done and supported only for legacy reasons.
  • the way that choice lists are used by search() is very specific to its implementation. It doesn't benefit from secondary instance usage the way normal selects do because there's no reason to query that special list with an instance() call and it only has one item so deduplication doesn't matter.

What we've done is gone back to generating inline selects only for selects that use search(). If you don't use search(), the change should not affect you in any way. If you think we've accidentally broken something unrelated to search(), please share a form definition that shows the issue with (updated with this fix).

With pyxform v2+, you should be able to use instance() calls to query any choice list specified as part of a select_* or select_*_from_file or attached with csv-external. That includes selects with any appearance other than the search() appearance/function.

Note that the search appearance (alias autocomplete), should be completely separate from the search() appearance/function and not be impacted by this change.

I hope I've addressed what you're asking about! If I'm still not quite understanding, please try what you have in mind against the converter so you can get the truest possible answer about actual behavior.

1 Like

Thank you @LN and the entire team.
I am able to upload the forms now.
I texted the forms on, then downloaded the xmlfile. Afterwards I uploaded the xmlfile on ODK Central and it worked.

Hi, is this problem related to this issue in github, please: ?

Only in that it also has to do with another undocumented way to get localized columns in a CSV. These two approaches are not compatible with each other.