I haven't been able to figure out a way to set the default language per content type - there are some cases (like for nodes created by RSS feeds) where I need a type to default to say French rather than the site-wide default of English.
Ideas?
Qasim
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | i18n-custom_default_language_per_node_type-2320183-2.patch | 3.55 KB | iamEAP |
Comments
Comment #1
iamEAP commentedI've found a need for this too. I'm attaching a patch which enables this functionality.
A couple of notes for people reviewing:
i18n_node_default_language_for[node_type]? Because there's already a variable calledi18n_node_default_language_none. If we removed the_forportion of the new variable name, it would be possible for the variable name to collide with a content type with machine namenone.customoption to thei18n_node_options_[node_type]variable? Because the behavior for "custom" and "current" are not mutually exclusive. If you were to select both, what would the behavior be? We can avoid that confusion by taking over the existing "current" value and displaying a new field in the event that it's checked. I've defaulted its value to effectively mean "current language," maintaining API backward compatibility.Comment #4
iamEAP commentedHmm. Test fails look totally unrelated to this patch. The latest 7.x-1.x-dev branch test hasn't run since December, so I'm not confident HEAD is working to begin with. Moving back to needs review manually.
Comment #5
joseph.olstadqueued for re-test
Comment #6
joseph.olstadI like this functionality, would be nice to have some extra feedback from the community. I'll probably be using this on my own projects soon.
Comment #7
joseph.olstadI just triggerred a few test runs. php 5.6, php 5.3 , php 7
Comment #8
joseph.olstadnice looking patch, haven't had a chance to test it yet. The php 5.6 test result can safely be ignored. something with the test environment for 5.6 that causes the single fail.
Comment #9
jollysolutionsComment #11
joseph.olstad