Just catching up on this thread… not sure what the cause of the issue is yet (or if it’s a bug or not). I’m new to using Drupal localization/translation features too so we’ll be learning together.
First thing to note: Drupal has two different “mechanisms” for localization. One is for “interface translations” (eg: all the UI text that comes in the module code), and one for “content translations” (eg: so you can have multiple versions of a record, each in a different language).
farmOS aims to support the former (interface translation), but not the latter (content translation), because we don’t foresee that being a need for most users (if you do need it, you are free to experiment with Drupal’s features yourself and report back), as opposed to cases where Drupal is used for a public-facing website where you want your content to be available to visitors in multiple languages.
The reason I’m outlining that is: from the perspective of API requests, I don’t think you should ever need to touch the
langcode attribute or any other language attributes for that matter. The records you create/update via the API are considered “content” and therefore don’t support individual content translations (farmOS does not turn that module on).
I believe that’s why the error message states: “… modify one of the translations that do exist: en” - that is referring to existing languages of the record you are updating. Records (content) will always be the default language of the site, which in the case of farmOS is always
en (even if you write your notes/etc in another language).
(There is a technical reason why the default is always
en, which you can learn more about here: https://www.drupal.org/project/farm/issues/3257430)
So… back to the issue at hand…
In order to determine if this is a bug or not, I think we need to replicate it in as simple a form as possible, to isolate whether or not it is caused only by the fact that @pat is using the
The way I would do this is: create a barebones API request that runs correctly on a non-translated instance, and then run that on @pat’s (or any instance with
farm_l10n enabled) and see if the error occurs.
Based on the thread above, I’m not convinced that a “correct” API request was made yet. And I would prefer to see
curl commands that are made outside of Node Red just to isolate that as a potential contributing factor.
@pat @Farmer-Ed would you two be able/interested in testing this out in that way together to see if we can get any clues?