My use case for this module is to provide enough demo content with an installation profile to make the "unboxing experience" of the distribution pleasant. The default content is kind of english but it's really just there to look pretty: http://glazed-demo.sooperthemes.com/news/500-growth-lorem-ipsum
If a user select a language other than english in the Drupal installer the demo content import will stop the installation process with this error:
InvalidArgumentException: Invalid translation language (fr) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation()
It's the same error as in https://www.drupal.org/node/2680135 but somehow that issue was closed with reference to a core issue. I guess this must be a different problem, or that op's problem actually was never solved..
I created a patch that checks before import if language fields are in the list of enable languages. If not, the content will be naturalised to the site's default language so that import doesn't fail. I think this should work without regressions for anyone. It should fix the use case of content that is only there for a pleasant unboxing experience that expects the user to edit or delete all default content.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2900089-14.patch | 4.72 KB | rajab natshah |
| #13 | interdiff-2900089-2-8.txt | 2.02 KB | jurriaanroelofs |
| #8 | naturalize-content-language-2900089-8.patch | 4.72 KB | jurriaanroelofs |
Comments
Comment #2
jurriaanroelofs commentedComment #3
jurriaanroelofs commentedComment #5
andypostCalled retest, Idea is interesting but is it fine to import EN content for RU/FR/... by overriding default labnuage... not sure
Instead of that for multilingual install profiles better to export all possible translations, we use that actively so each file contains content in all languages
Personally I prefer to enable default_content fixtures after custom profile install, so all languages from profile imported.
Other workaround is put all required languages into module with default_content
When no language available for translation I suppose it should be skipped but if no translations for selected in installer language available... here could be a fallback, but to which translation?
Comment #6
larowlanSorry, not an expert on i18n, one for @Berdir
Couple of general nitpicks
Can we use full word here, languages_available, current_language
thanks
nit: > 80 chars, needs trailing .
Can we use third arg, TRUE - we expect these to be strings so lets be type safe
I really dislike overloading an array like this. We should either create a value object or pass along $this->languageManager as user data instead, then we can typehint.
Comment #7
jurriaanroelofs commented@andypost I think you are judging this based on your own use case(s) for the default_content. To illustrate my use case, look at this page for example: http://glazed-logistics.sooperthemes.com/ – People do not install this default content because they appreciate my copywriting for a fictitious logistics company. The default content just makes the distribution look great out of the box and people will rewrite all content in whatever language they happen to be using.
If ever I translate my demo content I might only translate it to Chinese so that the content does not look completely alien to asian customers.
People will simply rewrite my default content and they will want expect the page to be in the language they selected in the installer, because they will be editing the default content in that language.
This patch doesn't conflict with use cases where multiple languages are installed and default content is provided in multiple languages, the patch is for the alternative use case where you want "vanity/designed content" that users will edit in their own language. I think this is a common use case for demo content.
Comment #8
jurriaanroelofs commented1. Fixed
2. Fixed
3. Fixed
4.
Sorry this is beyond me, I'm not very familiar with OOP programming. It's on my todo list but I think we'll have to assign this to someone else if this is important. Don't mean to be crass, this is my first patch for a Drupal 8 project and I'm just getting the hang of all the new stuff.
Comment #9
andypost@JurriaanRoelofs I understand your case perfectly, and another workaround for that could be implementation that config using in core - override language of modules' provided config to language that pointed in installer
IMO that's more workaround (hijack default language), primary because you breaks relations in default content that are language-dependent
OTOH it works for single language sites with single language default content - exactly like core works(
Let's get Berdir's opinion on it
Comment #11
andypostAlso please provide interdiff it makes easy to review changes you made between patches
Comment #12
andypostTo elaborate my idea check
- fallback to 'en' for unknown languages http://cgit.drupalcode.org/drupal/tree/core/modules/locale/src/LocaleCon...
- how locale module iterates localized config http://cgit.drupalcode.org/drupal/tree/core/modules/locale/src/LocaleCon...
I can't find where I seen overriding of default config language but translations do fallback to 'en' as well http://cgit.drupalcode.org/drupal/tree/core/modules/locale/src/LocaleCon...
Comment #13
jurriaanroelofs commentedThx.
Comment #14
rajab natshahComment #15
rajab natshahThe patch is the same Jurriaan's patch, only corrected the in_array call function
Comment #16
司南 commentedI get this error too, but in different context.
1. Create an installation profile as a distribution.
2. Add `default_content` module as dependency.
3. Add `content` folder in installation profile's root directory, then add some entity of hal_json format file.
4. Install drush form composer.
5. Run command: drush site-install my_profile ...
6. then the error occurs .......
How can i avoid this error?
my site's langcode is zh-hans and it is same with my default content.
Comment #17
geek-merlinI had this problem on a drutopia drush install and the patch fixes it for me.
Thought a bit about the approach, and a fallback like this totally makes sense to me.
Comment #18
psf_ commentedWork for me :)
Comment #19
anruetherThis patch does not apply together with #2698425: Do not re-import existing entities. Not sure if the error I get is related to the patch, but it didn't come up when the patch applied. Anyways, it would be great to get one of the patches or both in to have them working together.
Comment #20
berdirI've recently created the 2.0.x branch, see the project page on all the improvements in the 2.0.x branch. Testing that and providing feedback would be very welcome. The 1.x branch isn't actively maintained and won't receive new features anymore, so I'm closing this and other issues as won't fix.
2.0.x explicitly supports multiple translations and also handles language mismatches.. non-existing languages are ignored and if the default language doesn't exist, it will either pick one of the available translations or fall back to the default language of the site being installed.
Comment #21
eduardo morales alberti@Berdir, its still happens on 2.0x branch.
I refactor this issue patch after applying the issue https://www.drupal.org/project/default_content/issues/2698425 patch as comment @anruether
Comment #22
eduardo morales albertiStill getting the message, so the patch does not fix the error
My solution was delete all the entities generated and regenerate it again.
Comment #23
eduardo morales alberti