kaliop-uk
Undefined index: eng-US when updating content_type
Current ezplatform version 2.2
Trying kaliop/ezmigrationbundle ^5.0
Getting this after running a migration for modifying the article content type.
I was missing this languages: [eng-GB] from my site_group in ezplatform.yml
I thought that line could be removed. I was using ezplatform-ee-demo as a reference
Right so I see a pattern now. If I remove from ezplatform.yml -> site_group -> languages [eng-GB] and my default siteaccess is set for eng-US kaliop fails when updating a content_object that was originally created in eng-GB. And if I add languages [eng-GB] back to the site_group then kaliop works as it sees the default for the site_group is eng-GB. But this screws up the translations so I can't do /fr /us /uk anymore as it will always default the locale to en_GB because of site_group.
Hello. Sorry for taking such a long time to come back to you.
I think that, in a multilanguage scenario, you should have in your configuration languages: [eng-GB], as by default all content-types and core contents (admin and anon users, user groups, etc) are created in eng-gb.*
But you should add to it all other existing languages as well, so that the config (for both the siteaccess group and for the admin siteaccess) would look like: languages: [eng-GB, fre-FR, eng-US].
Then you should redefine the languages setting for each frontend siteaccess which is meant to display a single language.
I don't think that the configuration outlined above would screw up your translations, unless there is a bug in the eZ kernel's handling of the override for the languages setting.
And, even if there was such a bug, it would not be a bug in the implementation of the migration bundle - just make sure that you use the correct siteaccess when executing migration commands.
Please let me know if all of the above makes sense / works for you, so that we can close this ticket.
[*] = ps. another option is to 1st translate all eng-GB stuff to eng-US and then remove eng-GB from configuration, however this is tedious to do manually and error-prone to do via custom SQL queries...
