Problem/Motivation
The current language settings for node types has some limitations. The site builder wants to choose what happens when a content type has multilingual or not.
The language options when adding a node are:
- None
- Site default language
- Page language
- Default value
- User language (#40)
When configuring a content type it should be possible to set a default for and allow to pin the language option.
Proposed resolution
Image taken from #88
How to test
- Enable Content translation module
- Visit content type config page, e.g.
admin/structure/types/manage/article
- Select 'Language settings' tab and set some settings.
- Next create an Article and see whether those settings apply.
- Check the translation tab and add a language.
- Try to translate the Article into the new language.
- Repeat the process to try all of the possible settings.
- ? more steps ?
Remaining tasks
Review these test cases (#116):
- tests the default initial language
- the default lock language option
- the site's default initial language option
- changing the initial language option
Still needed tests tests:
- update test
- user default initial language
Are there more tests needed?
Use entity_create according to #42.
This issue is not only about node types but should work in the end for all entity types. So we need a list of all related issues here.
User interface changes
tbd
API changes
tbd
Original report by dvinegla
GaborHojtsy clarified: #31 http://drupal.org/node/258785#comment-5602950
In you creates content type without language support, default language is assigned to it.
I think it must be '' (neutral) or FALSE
Comment | File | Size | Author |
---|---|---|---|
#216 | node-type-changelog.patch | 574 bytes | Gábor Hojtsy |
#211 | 258785-211.patch | 30.02 KB | Schnitzel |
#211 | interdiff-204-211.txt | 4.47 KB | Schnitzel |
#204 | interdiff-202-204.txt | 2.13 KB | Schnitzel |
#204 | 258785-204.patch | 30.31 KB | Schnitzel |
Comments
Comment #1
desbeers CreditAttribution: desbeers commentedI completely agree. For example, the i18n module for D6 has the option to filter content and one of the filter-options is 'including neutral'.
Let's say you create a custom node-type that just contains a photo; it's language-neutral and it's silly to assign the default language to it.
I found this problem while upgrading my site form D5 to D6 and added the 'translate' function only to stories and not for pages yet. New pages didn't show-up when visiting the 'non-default' language version of my site.
Attached patch just removes the 'offending' code in function locale_form_alter() in locale.module. and the SimpleTest didn't complain after running the tests.
Comment #2
bensemmel CreditAttribution: bensemmel commentedHad the same issue. Thanks for the Patch. It is working for me as well
Comment #3
lilou CreditAttribution: lilou commentedLook good and all tests pass (thx Testbed ;-)
Comment #4
Dries CreditAttribution: Dries commentedI'd like to have Gabor review this.
Comment #5
Gábor HojtsyI think that there are more levels here. While for photos, this looks like a valid use case, you might have other areas where this does not apply. For example, you have a single foreign language blog (let's say French), there you would not enable language selection for blog posts, since you only have one language. But your blog posts are definitely not language neutral, they are French. So there might be two options to not add language selection to a content type: to assign default language or to assign language neutral. This could be another possibility in the locale module provided settings additionally to what we have on content types already.
If you language-enable a content type, it means you can select from at least Language neutral and a specific language, so it is not a one-op thing as you assert.
Comment #6
thePanz CreditAttribution: thePanz commentedI'm with Gàbor! A setting for default-language is needed: none (or language neutral) or Default (default site language)
I know that this feature won't be added into D6, but will be useful to have some module that implenent this (and maybe also http://drupal.org/project/preserve_language features).
Regards
Comment #7
Alice Heaton CreditAttribution: Alice Heaton commentedFollowing a request from thePanz, the Preserve Language module now implements this fix for Drupal 6. The code was contributed to the module by thePanz.
I've only just committed it to CVS - so package might take up to 12 hours to be ready.
Comment #8
drewish CreditAttribution: drewish commentedi think goba's got the right idea here. but i think that even the photo example is a little too simplistic. photos usually have a caption or title and that's going to have a language.
i've usually had to form alter the language selector to remove language neutral out of certain node types because they always have a language. but i'm using the active translation module to handle the selection of content for languages so my needs may be different than most.
Comment #9
David Lesieur CreditAttribution: David Lesieur commentedI'd love an option as proposed by Gábor in #5. Furthermore, I think that for language-enabled content types, admins should be able to remove the "language neutral" option.
On a particular project, I wish to avoid language neutral content, and show the original nodes to visitors when a translation is not available in their language. To avoid a "duplicate content penalty", I want all nodes to have a language in order to be able to instruct robots not to index a node when the current language is not the actual language of that node—something we can't do if nodes are "language neutral".
So far my plan to achieve this involves:
Hopefully, this discussion might help solve step 3 in D7.
Comment #10
dvinegla CreditAttribution: dvinegla commentedrelated issue: #374404: Create alias only works in one language
Comment #11
Pasquallesame alias problem here: #311158: default node language
I almost agree with Gábor, but the language of non-multilingual nodes should be configurable per node type. I may want a node type which is not multilingual, not language neutral and not written in default language.
But there is still a question what should be the alias language? Let's say node/5 is not a multilingual node and it has an alias. If I use url('node/5') then the alias should be used regardless of the active language and the node language.. So I guess alias language for non-multilingual nodes should be language neutral..
And as far as I know if the locale module is not enabled then all nodes are language neutral. So it is problematic when creating some nodes and enabling the locale module later.. Maybe a bulk update checkbox when changing the language of non-multilingual node types..
Comment #12
marcushenningsen CreditAttribution: marcushenningsen commentedThis would be a great feature. It's very tedious to go through each alias to change it into "neutral language". If you can bulk promote to frontpage it should be possible to bulk change language.
Comment #13
voxpelli CreditAttribution: voxpelli commentedThis needs to be fixed since the current behavior is very inconsistent.
Language neutral is default when locale.module isn't activated and also when it is activated and the multilingual support is enabled. The default all of the sudden is the site's default language though when locale.module is active and the multilingual support is disabled - which is currently the only time it's the default language for a node.
I think that the default behavior should always be neutral unless you actively choose otherwise - it would result in the most consistent behavior. I don't think the expected behavior for a new user of locale.module is to have all of their new content to become the default language - it's just confusing.
I'm attaching a patch that makes it configurable for each content type whether to default to neutral or to the site's default language. I've made neutral the default in the patch for the reasons I mentioned above.
Comment #14
voxpelli CreditAttribution: voxpelli commentedAlso - I think this should be a feature request and not a bug report, no matter how annoying the current behavior might be...
Comment #16
plachsubscribe
Comment #17
donquixote CreditAttribution: donquixote commentedAgree with voxpelli.
I would love to see a module to fix this for D6.. or actually, I would love this to get fixed in the D6 locale module itself.
I'm not sure if the "Preserve Language" module is mature enough? I think for now I will code my own.
Comment #18
donquixote CreditAttribution: donquixote commentedAnyone who needs a fix now can use the attached module.
Comment #19
klonosDoes the latest patch work in D6?
Also, I believe this would be better if it was an option. Some people want it to be set to neutral, others need it to remain set to the default site language, others might want to set this to a specific language. They all seem to have legit reasons and use cases. So, perhaps a setting in the language options would satisfy all these scenarios.
There could be a 'Language for content types without language support:' set of radio-boxes that would offer the following options:
- Set it to language Neutral.
- Set it to the site's default language.
[... list of all enabled languages ...]
- Language 1
- Language 2
- ...
What do you people think?
Now, I haven't reached the level of Drupal knowledge (yet) where I could re-roll patches with my suggestions, but as far as I can tell all there needs to be added to the previous patch in #18 is a variable that will hold the setting and the set of radio-boxes in the language settings page that would allow this variable's value to be set through the UI. Anyone up to it?
Comment #20
plachI am afraid this will have to wait for D8 :(
Comment #21
klonosthat's too bad :(
D8 means year(s) till this is finally fixed!
Comment #22
plachUnfortunately we are way past over D7 feature freeze, we'll have to cope with this in contrib for another release.
Comment #23
Gabriel R. CreditAttribution: Gabriel R. commentedIn real life and with no holier-than-thou logic attached, not setting a language to a language neutral node is the only sane thing to do. Apply the change in patch #1 safely.
You will want then to go into the DB and update the `node` table to set `language` to an empty string for the previously created elements. Not fun.
Comment #24
donquixote CreditAttribution: donquixote commentedYes, there are more levels:
The French blog post is French, but it is not intended to be a part of the "french version of the website". Instead, all visitors are supposed to read all blog posts, no matter if French or Italian.
On the other hand, the French start page is only intended for visitors who switch the site language to French, while the Italian visitors are supposed to see the Italian front page.
Thirdly, there might be some "French FAQ" and "Italian FAQ" nodes, that only apply to the language of the reader, and where FAQ nodes in French have no direct counterpart in Italian.
And then we could have an international forum, where people write in any language they like (or mixed), and can't be expected to set a post or comment language.
Other sites could follow a different philosophy.
The real problem is not the post language, but the content selection logic.
The Active Translation module addresses this problem, and can solve it to some extent:
The French blog post does not have a translation associated with it, so it will be visible to Italian users. The same for the front page, as long as it is not translated. Once a translation of the front page exists, the French version will be hidden from Italian visitors in node listings.
The French FAQ nodes will never have a translation, but still they should be hidden from Italian visitors, who have their own FAQ section (that might be structured in a different way, because it is maintained by the Italian FAQ team).
Another point:
For some sites I made, I started with English (because I want to see an English admin interface), but the content was all in German. Of course, Drupal would tag all the content as English, because that was the default language.
Comment #25
AdrianB CreditAttribution: AdrianB commentedSubscribing.
Comment #26
HnLn CreditAttribution: HnLn commentedsub
Comment #27
clashar CreditAttribution: clashar commented+1
Comment #28
rwt CreditAttribution: rwt commentedHow to force "Language Neutral" as default in Drupal 7, hack :
Comment #29
marcushenningsen CreditAttribution: marcushenningsen commentedI can confirm that this "hack" works perfectly. It's shame, though, that this isn't default behaviour in Core.
Comment #30
clemens.tolboomThis kinda blocks #158803: Hide "Language" column in content overview table if only one language is enabled
Comment #31
Gábor Hojtsy1. So what we have in Drupal 7 is that nodes default to "Language neutral" until you enable Locale module.
2. Then nodes will still default to language neutral but you can enable language support on node types.
3. Those node types will let you choose a language from a dropdown (which includes all your configured languages and language neutral). But it will still default to language neutral.
So Drupal 7 already fulfilled the goals of the original poster:
Now however many people complain that this is not the right way to do stuff. Ehm. @clemens is complaining about that at http://drupal.org/node/158803#comment-5602838
So people are not happy either way, so looks like we need to figure out what is the better sensible default and apply that + looks like we cannot forgo providing a setting. All this is of course only possible in D8. Retitled for that.
Looking at what i18n module provides I think we can get some ideas as to what people wanted so far:
A. For no-mutlilingual support nodes (1) default to site default language (2) default to none
B. For multilingual-supported nodes (1) default to current page language (2) default to none
C. For multilingual-supported nodes (1) remove language none from the options (2) keep it
D. For multilingual-supported nodes (1) lock the language (2) keep it selectable
I think B1 makes sense for A cases too and D1 is basically more like driving back towards A (we tell what should it have and not the users). So looks like we have three questions to answer:
I. What should be the default language for this content type? (page language, site default, none)
II. Should we lock the language for this type? (formerly multilingual support enabled/disabled)
III. Should "none" be an option for this content type? (yes/no?)
Then keep in mind we want to generalize language to all entity types, and these sound like reasonable settings for any entity type (eg. taxonomy terms, users, etc).
(i18n also supports listing disabled languages for assignment, not sure we should lump it up here if we want results sooner than months).
I don't agree with @clemens that this would block #158803: Hide "Language" column in content overview table if only one language is enabled though, so I think we can keep working on both in parallel.
Comment #32
Gábor HojtsyBTW definitely postponed for now on #540294: Move node language settings from Locale to Node module because that moves around the code that this patch would largely affect.
Comment #33
Gábor Hojtsy#540294: Move node language settings from Locale to Node module landed, so this is now unblocked! Let's validate the plan I've outlined then!
Comment #34
Désiré CreditAttribution: Désiré commentedJust a first try, for testing.
Comment #36
Désiré CreditAttribution: Désiré commentedFixed variable_get calls.
Default language is selected on node add form.
Comment #37
pkiraly CreditAttribution: pkiraly commentedCreating default language settings on node type form, and using the default language in node add form.
Comment #38
pkiraly CreditAttribution: pkiraly commentedThe previous changes and moving the node_type_language_enable_translation form element from node type form to translation module.
Comment #39
Désiré CreditAttribution: Désiré commentedComment #40
fubhy CreditAttribution: fubhy commentedPersonally, I prefer having double quotes around the string when there are single quotes required IN the string.
So instead of t('Site\'s default') better use t("Site's default")
The brackets are not required in 'name'.
Just use isset($user->name) ? $user->name : '' instead of (isset($user->name) ? $user->name : '')
Comment #41
fubhy CreditAttribution: fubhy commentedYes, looking good now.
Comment #42
pp CreditAttribution: pp commentedPlease show settings at description of fieldset like "Publishing options": Published, Promoted to front page.
Some screenshot:
Comment #43
Gábor Hojtsy"Language settings" or "Language configuration". It is not necessarily multilingual if there is a single language only.
We usually use "" to wrap text with single quotes in them.
Let's brainstorm a better name for these.
Putting on my @yoroy hat here :) 1. This is a select box, so we don't need to document that the user needs to do that. 2. Language is repeated twice (and we already know from the options and label). 3. Node is the internal technical term for content.
So what about: "Used for newly created content." or something similarly simple.
"Lock language" IMHO
"Users will not be able to change the default language on content of this type." maybe? Not sure.
Maybe document why we need this? Do we need it at all? I don't get why?
I'm not sure this adds value to the checkbox? It reiterates the same thing?
Comment #44
clemens.tolboomThis should use entity_create?
See http://api.drupal.org/api/drupal/core!modules!entity!entity.module/funct...
See devel : #1375800: Fatal error: Call to undefined method stdClass::save() when generating comments
Comment #45
Gábor HojtsyTalked with @Bojhan about the intro text on the fieldset. It does not add much value, so what about removing it?
Comment #46
Gábor HojtsyAlso we have been thinking about how to hide the language as well, since the current patch degrades functionality for those where "Disabled" was selected for language before. Earlier the language select was not shown, this one shows the item. I think we should make some improvements there. Ie. make locked a three way option:
- Selection dispalyed
- Locked and hidden
- Locked and shown
And the last option would hide the value. Mid-option would show the language but not as a #disabled select, since that sounds like freaky for a user. I'd use an #item field for that for display. Not sure about the name of the options, but I think we'll need the three options separately. I thought about a "visibility" setting as well (to separate from the locked feature), but that would not have much meaning in case the value is not locked but not visible either (that would effectively lock it). So sounds like there is an overlap which means we'd want to have it in one option set.
Comment #47
Désiré CreditAttribution: Désiré commented@pkiray and I have merged our patches.
- Update and uninstall hook.
Some documentation needed....
Comment #49
Gábor HojtsyCan you post updated screenshots? Thanks!
Comment #50
cosmicdreams CreditAttribution: cosmicdreams commentedYea, in general the documentation isn't where it needs to be.
Every function that has a return needs a @return in it's documentation. I'm trying to cut my teeth on this issue by making a best effort with that one thing.
Comment #51
andypostPatch needs re-roll
Comment #52
andypostVery interesting issue so I take it to make some progress... by my own.
I think we should minimize variable and option usage on settings.
Translation module already works by the same as it now.
if node is not translatable why it's langcode could be different from LANGUAGE_NONE?
When node translatable we just need to limit user's ability to change language and provide sensible defaults when user disallowed to set node language.
Last patch done before conversion from language to langcode so needs rework
Locked does not mean none-multilingual
We should add some .js magic to make it work as all other node's VTs
Copied from translations module and needs to be more clear.
I'm going to fix this in translation module too.
translation alters this piece so needs more attention here
there's no more variable indicating multilinguage type for node-type?
Should live in node.module to be accessinble for other modules
not sure we need 3 vars per node-type
deprecating *language_type* we need change notice and a new way to allow other modules to know a default language for node
langcode for now!
Do we really need to change defaults for node?
BTW node_type_get_default_language() should be alterable or should use a variables to allow i18n change it's result
no variable to detect "multi-language-ability" of node
#disable is bad way, suppose better to #value if locked
3rd variable? seems overkill
Comment #53
Gábor HojtsyNot sure you are looking for feedback on the first question, but the sentence you posted right after that would be the answer :) That a node is not translatable does not mean it should always be LANGUAGE_NONE. It is more likely that it would be a fixed language to something (typically site default). A major aim of this patch is to make that configurable, so the binary on/off language support on node becomes more granular where you can set defaults and whether users should modify them or not.
What's a multilingual node type? :) The proposed patch does away with that concept and instead provides flexible options to default nodes to certain languages. So if you'd default your content type to language none and fix it to that, that would be quasi equivalent to D7 behavior (minus it not being hidden, see below).
Well, #disabled and type value are two different answers because they provide different levels of visbility. If you make it a value type, the language will be hidden from the user (not just locked). If you make it disabled, it will be locked but not hidden. I was lamenting on the missing "hidden" functionality in #46 above. Maybe we should have a "hidden" feature instead of a locked feature and leave locked but visible to contrib?
Comment #54
andypostSetting up i18n and entity translation we have a lot of settings (screens bellow)
Currently we have only one variable in core (I {t} as suffix for node-type)
Suppose we should rename it to
node_type_translation_type_{t} - determines a way to translate a node
For D7:
language_content_type_{t}
Now in D8
node_type_language_{t}
changed in #540294: Move node language settings from Locale to Node moduleThen we can add another options as i18n does.
i18n uses it's own set of variables
i18n_node_default_language_none - Default language for content types with Multilingual support disabled.
i18n_node_options_[node_type] - Extended language options
i18n_node_extended_[node_type] - Extended language support
Comment #55
Gábor Hojtsy@andypost: yes, this issue is about the initial language for content types. We cannot fix everything at once IMHO without stacking confusing settings on top of each other like i18n does. So this issue is about the initial language, therefore i18n's 1st and 3rd checkboxes apply and the radio buttons do not apply. For the list of languages that apply to certain things (the middle checkbox and the radio buttons), see #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc).
So we talked about introducing (a) flexible defaults for language (b) the possibility to lock language. These two allow to keep the core functionality by mapping to the new settings AND also provide a rich set of new settings (and conveniently sized so we can actually solve it without debating it to death endlessly and keeping the current mess in indecision). The mapping of existing functionality (Drupal 7) to the new settings proposed in the patch above would be:
(The node translation method is planned to be integrated with the field translation method, so we'll only have one way).
Note that these settings do allow users to set different flexible defaults, the ones provided in the above table are the D7 defaults for the corresponding settings, this will not necessarily be the D8 defaults.
Once again, this issue is about expanding the initial value configuration for nodes. In D7 you could only lock a node type to LANGUAGE_NONE and if you allowed selection of language, it always defaulted to LANGUAGE_NONE. By refactoring the settings to be more flexible I think we make the feature more understandable (I got lots of questions on what multilingual support enabled means, now the options spell it out :).
For the list of languages available, #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) is the relavant issue, not this one. Scope and intention clearer now?
Comment #56
Désiré CreditAttribution: Désiré commentedRerolled patch for testbot.
Comment #58
Désiré CreditAttribution: Désiré commented- node_type_get_default_language moved to node.module, renamed to node_type_get_default_langcode
- fixed array key 'langcode' in node_add function
- Language settings vertical tab moved to locale.module
- JS magic for language setting vertical tab summary
Comment #59
Désiré CreditAttribution: Désiré commentedtest it please....
Comment #61
Désiré CreditAttribution: Désiré commentedSome updated tests.
Comment #62
Désiré CreditAttribution: Désiré commentedComment #64
Désiré CreditAttribution: Désiré commentedComment #65
Désiré CreditAttribution: Désiré commentedCorrected patch (no gitignore...)
Comment #67
Désiré CreditAttribution: Désiré commented- Site's language by default on content type setting page
- probably no test fails...
Comment #69
Désiré CreditAttribution: Désiré commentedlanguage_from_default() function depends on locale module, so use language_default()->langcode instead.
Comment #71
Désiré CreditAttribution: Désiré commentedA new node has now the sites default language by default.
Comment #72
Désiré CreditAttribution: Désiré commented- language options vertical tab in node module (content_types.inc)
- uninstall hook for translation module: sets translatable content types to selectable
- use 'node_type_language_selectable' variable instead of 'node_type_locked' and 'node_type_translation_enabled' (both language locked and translation enabled can't be TRUE #258785-55: Provide more flexible settings for initial language on content types)
- use radio buttons instead of 2 checkboxes
Language settings without translation module:
Language settings with translation module:
Comment #74
andypostLocked and no hidden? should we introduce new core's permission - change/set content language?
Comment #75
Gábor HojtsyI dont think this is a permission question, it is about configuruing which types you want to tie to which languages. Such as if you have a multilingual site but a monolingual forum, you could tie those nodes to your default language. Or if you have a product pictures file set, you could tie those to language not applicable.
Comment #76
andypostI suppose if site has different editors for different language parts so changing a node's language should have moderation (permission to change language of node's type)
I'm talking about nodes Only!
The assumption I made is that disabled language elemnt would confuse a bit more then hidden. OTOH l18n does not provides Hidden option (default + reqired + locked)
Comment #77
Gábor Hojtsy@andypost: yes, language based permissions make sense (eg. These users can only create/edit X language nodes), but that is not at all the scope of this issue. This is simply about giving more versatile options for setting how the language is initialized on nodes.
Comment #78
Kristen PolComment #79
pixeliteThe UI for #72 looks great! I would suggest the following changes to the labels:
Since the language options include whether the nodes can be translated as well as whether you can select a language, I think changing the label from 'Language selection' to 'Language options' makes sense.
Comment #80
Kristen Pol1) I like the naming that @pixelite suggests better than what is currently on the UI mockup.
2) I installed the patch and went to edit a content type and got this error:
Comment #81
Kristen PolRegarding Default language:
1) Wondering if the label should be more descriptive though maybe it's obvious enough, e.g.
Default language for content
or
Default language for nodes
2) For some reason, I find the "Special options" label confusing though I'm not thinking of a better alternative at the moment.
Comment #82
klonosThe wording as is helps the tab's quick info text make sense in a glance (even when the selected tab is a different one from the "Language settings"). Consider the current variants:
Hungarian, Locked
Hungarian, Selectable
Hungarian, Selectable with translation support
To the ones suggested in #79:
Hungarian, Locked to Default Language
Hungarian, User Selects Language
Hungarian, User Selects Language, Translation Enabled
Personally, I like it better the way it is now. It's shorter and it makes sense.
Comment #83
Berdir@see's to issues are usually not added to core, unless there is a very good reason to that is relevant in the future. E.g. you having to do a workaround due to a an issue in another module that you can't fix, or reference to a issue that's still open.
Additionally, this would actually make it show up in the UI I think.
No idea if the comment here is still necessary as the new code has no checks or special cases anymore. I guess it's now documented in the place where $node->langcode is set.
The constant can't be used in the .install file, that's causing the notices in the test.
There are also various rejects in the patch due to the language_none rename patch. I guess the new function that returns the language needs to be updated as well.
Comment #84
Schnitzel CreditAttribution: Schnitzel commentedReroll of the patch, because
LANGUAGE_NONE
has changed toLANGUAGE_NOT_SPECIFIED
Comment #85
Schnitzel CreditAttribution: Schnitzel commentedthis is fixxed in the attached patch.
The other comments from Berdir are not yet included!
Comment #87
Schnitzel CreditAttribution: Schnitzel commentedhad a talk with Gabor about the the new settings.
The Problem is, that with the RadioButtons it was not possible to set the Default Language "Locked" but still be able to translate it. So we need there Checkboxes.
I changed the code back that it uses Checkboxes. Also changed this:
- Added JS which disables "Enable Translation" Checkbox when DefaultLanguage is "None" and "Locked"
- Wrote also an Field Validator for the same case
- fixxed @see problem in update hook (it really showed in UI)
- fixxed using of constant in translation.install
Comment #88
Schnitzel CreditAttribution: Schnitzel commentedhere a short picture how it looks like now
Comment #89
Kristen PolI applied the patch and it said it was going to create a file that already existed but it seemed to be successful:
Comment #90
pixeliteThe UI looks good. I've tested the patch in #87 with various configurations and it works well.
Comment #91
Kristen PolFeedback on patch so far:
Comment #92
Désiré CreditAttribution: Désiré commentedGreat work!
'Lock language' and 'Translation enabled' options are mutually exclusive. (You can't translate a node to hungarian if the type is locked to english.) (This was the reason why I originally used radio buttons for this...)
Now we need validation for this, and probably a javascript (or states) solution to uncheck 'Lock language' when 'Translation enabled' is checked, and vice versa. And probably a description line.
The patch still needs automated tests:
- for update hook
- for changing the initial language of a node
- for changing the sites default language
- for 'Lock language' option
Comment #93
Kristen Pol@Désiré Thanks for the clarification. Makes sense!
Should the language be locked by default? I wasn't sure if that is the desired behavior though it seems reasonable (e.g. locked and site default language).
Comment #94
donquixote CreditAttribution: donquixote commentedHi,
I have not exactly followed this issue in all detail, but I have a more general comment about language selection for content.
If a node has entity translation (translation per field) enabled, that means there is one nid for multiple languages. In theory, the node should be language neutral, whereas each of the localized versions does have a language. In practice, when you create a node with entity/field translation enabled, this node needs to be given a language - usually the site default.
I think this is not totally wrong, but it does give the language setting a different meaning, and should rather be named "source language" than "node language". The node itself has multiple languages, it is just that one of them is used as a source for the translation process, and as a fallback.
This distinction does become relevant
I hope this does help anyone..
Comment #95
klonosNope, if a nod id has multiple languages, then it should be marked as such - not as language neutral. It seems that we are going to have LANGUAGE_MULTIPLE: #1471432: Rework language_list(), let people use more special languages
Comment #96
Schnitzel CreditAttribution: Schnitzel commentedWhy not? Maybe there is a missunderstaning. We actually don't copy the functionality of Language Locking in D7 with i18n. In there the locking means that you cannot change the language after a node is created.
With the locking in D8 you force the node from the beginning to have a specific language setting.
So right now I'm not really sure if we need Radios or Checkboxes.
I could maybe imagine this usecase:
You have multiple languages enabled but want only 1 language as source language and the other languages should only be translated via a contrib Module such as TMGMT. Then Locking is required and Translation should also be enabled.
Yes, this is the same as in D7 when you had Multilanguage Support disabled (which is also default there)
Comment #97
Schnitzel CreditAttribution: Schnitzel commentedAgree with klonos #95, as far as I understood, that in D8 you don't select Node or Field Translations anymore, this depends on the Lanuage Setting of the Node. If it has "Multiple", then Field Translation will happen.
I am right with this?
Comment #98
donquixote CreditAttribution: donquixote commented#95, #97
sounds good :)
My comment #94 was totally uninformed then.
Maybe it's time to update the issue summary.
That said.. even if a node/entity is set as multi-language, there is still one language that is the "source", isn't it? Or are they all equal?
Comment #99
klonosGood question Andreas! Anyone know how we'll be tracking this now? Will the original language fields be marked as source somehow?
Comment #100
Gábor Hojtsy@klonos: we documented the field language support stuff yesterday at http://drupal.org/node/1500308 :) hopefully that answers your question proper. If not, we need to improve there, so we don't need to explain this 1-1 to people all the time :)
Comment #101
klonosThanx Gábor, I wasn't aware of that handbook page. It seems to be explained perfectly there and if something needs to be improved it should be done there as you say.
If I got it right we'll be using
$entity->langcode
(in entity/fields based translation) to figure out the "source" language of a filed that has translation enabled instead of usingtnid
like we did with content translation. Right?Comment #102
Gábor Hojtsy@klonos: yes.
@Schnitzel, @Desire: can either of you continue working on this? It would be great to make this land sooner than later :) Also I still would like to underline that the "hidden language selector" feature that is present before the patch is not present with this patch added. So for content types where language is locked, the selector will always be visible, right? I think we need to make sure to figure out something good for that. Maybe rename that to "locked and hidden" and make it hidden as well by default. Then contrib will be able to show it if they want it. I think it would be important from a usability PoV now to show disabled fields, when we don't need to.
Comment #103
andypostIMO Locking is confusing and produce more questions from editors: why it could not be changed? and also eats a screen for useless option and makes content edit form harder to understand for newbies
Comment #104
Gábor HojtsyOk, so what about if we make it hidden then and say it is "Hidden"? It would make it locked too in essence, since you'd have no UI to change it. That would keep the core functionality while making it more flexible.
Comment #105
Désiré CreditAttribution: Désiré commentedAnd what if we use 'item' instead of 'select' for the locked language on the node edit form? (And probably a short description)
Comment #106
Gábor Hojtsy@Désiré: that is still a functionality change and it would be hard to get in a patch that removes functionality without any good reason. Let's keep the setting here for setting initial language and not exposing it if the user chooses that. That is the existing functionality (except you cannot pick the default dynamically, which is what this patch is about). We are past 100 comments, which is a clear warning sign we should not blow up the scope :)
Comment #107
Gábor Hojtsy@Désiré: are you working on this?
Comment #107.0
Gábor HojtsyUpdated issue summary.
Comment #107.1
clemens.tolboomInserted a (short) issue summary.
Comment #108
clemens.tolboom#87: 258785-more_flexible_initial_language_on_content_types-87.patch queued for re-testing.
Comment #110
clemens.tolboomAttached is a reroll from patch #87 ... there was one problem with content_types.js so please review that again please.
(I ran
patch -F100 -p1 < ../258785-more_flexible_initial_language_on_content_types-87.patch
which succeeded to apply)Comment #111
clemens.tolboomSee #1419968: Replace $('selector', domelement) with $(domelement).find('selector') which we should apply too.
Comment #111.0
clemens.tolboomFixed typo and broken image.
Comment #112
clemens.tolboomI've updated the Issue Summary twice: Added an Issue Summary template and added step 'How to test.' which I hope helps others to quicken their review.
@Gábor Hojtsy : Are there issues for entity language settings yet? Maybe we could fill-in the remaining tasks with those.
(sorry for the many updates)
Comment #113
Désiré CreditAttribution: Désiré commentedStill needs automated tests.
Comment #113.0
Désiré CreditAttribution: Désiré commentedAdded 'steps to test'
Comment #114
clemens.tolboomI updated the Issue summary a little for 'Remaining Tasks'
@Désiré: could you update the issue summary 'Remaining Tasks' to make a complete list of tests. Tnx :)
Comment #115
Gábor HojtsyNo we don't yet know how to abstract this to a generic config UI for entities yet. I believe we don't have a common entity settings form concept ATM, do we?
Comment #115.0
Gábor HojtsyUpdated issue summary.
Comment #115.1
Kristen PolUpdated issue summary.
Comment #116
Désiré CreditAttribution: Désiré commentedHere is a rerolled patch, with some test cases:
- tests the default initial language
- the default lock language option
- the site's default initial language option
- changing the initial language option
missing tests:
- update test
- user default initial language
Comment #116.0
Désiré CreditAttribution: Désiré commentedUpdated issue summary.
Comment #116.1
Désiré CreditAttribution: Désiré commentedUpdated issue summary.
Comment #117
Désiré CreditAttribution: Désiré commented#116: 258785-more_flexible_initial_language_on_content_types-116.patch queued for re-testing.
Comment #119
Désiré CreditAttribution: Désiré commentedFixes in drupalCreateNode().
Comment #121
Désiré CreditAttribution: Désiré commentedAll tests fixed:
The default initial langcode of a node is the site default,
BUT the array key of the content fields (like node body) is still LANGUAGE_NOT_SPECIFIED ('und')
Comment #122
Désiré CreditAttribution: Désiré commentedComment #123
Ujin CreditAttribution: Ujin commentedseems patch need reroll
Comment #124
andypostSuppose langcode for node fields is out of scope for the patch
Comment #125
andypostThis hunk should be rewritten in #1539072: Support for disabled languages broken, drop it
Comment #126
Gábor Hojtsy@andypost: thanks for the review. Indeed #1539072: Support for disabled languages broken, drop it would not apply if this will land first.
Comment #127
Gábor Hojtsy#1539072: Support for disabled languages broken, drop it landed first, so this will need all disabled language handling removed. Thanks for your great work so far!
Comment #128
ArtusamakComment #129
perusio CreditAttribution: perusio commentedI'm wetting my beak with this.
Comment #130
ArtusamakI'm still on this issue, i'm reassigning it to myself. ;)
Comment #131
ArtusamakFirst attempt on this reroll, going home and need to some how is the testbot behaving.
Comment #133
Désiré CreditAttribution: Désiré commentedWhy changed the modes?
Comment #134
Désiré CreditAttribution: Désiré commentedOn a node edit page, or a translation page the $node object has already the correct langcode variable, so this code are unnecessary.
This can be set up in the node_add function, just like in the previous patches.
Comment #135
Désiré CreditAttribution: Désiré commentedThe patch in #131 was wrongly rerolled, so I rerolled the patch from #121 again.
Comment #136
andypostWhat does it mean? Any reason to depend a comment language on locked state?
We have no support for disabled languages after #1539072: Support for disabled languages broken, drop it
Comment #137
Désiré CreditAttribution: Désiré commented1.
Node types was LANGUAGE_NOT_SPECIFIED language by default and, when a node type was multilingual support, a comment gets it's language from the node. But now all content types has language support, so you have right, this modification is wrong, instead, now the comment can always get the langcode from the node.
2.
In the latest patch (in #135) don't contains support for disabled languages.
Comment #138
andypostThis require a shord comment why comment language uses this kind of language
Don't use t($var). Suppose $language->name is enough to choose
Do this related to the patch? You are going to change to much!
Comment #139
Désiré CreditAttribution: Désiré commented- Comment added to comment language (as mentioned above)
- Misused t() removed from content_types.inc (as mentioned above)
- patch rerolled
I think this is related to the patch, because from now a node type gets the sites default language by default for initial language, so drupalCreateNode() should use this for default settings. (btw I think, it couse test fails, if we leave it LANGUAGE_NOT_SPECIFIED, so I attached a patch for test this)
Comment #140
Désiré CreditAttribution: Désiré commentedComment #141
Gábor HojtsyLooks like the "should fail" patch did not fail. Hm. Here is a deeper code review with things that people did not seem to catch yet. Surprising this was RTBC for some time given these findings. :/
The previous code allowed to preset the comment language (and only defaulted to node language if it was not preset to a concrete language). This is not happening anymore.
Hm, why would you change these?
I'd explain what "current language" means here. Is it interface language, content language? (Unless we replace this with a dynamic list of all language types defined on the system, I'd suggest we hardcode "current content language").
Why is this TODO not implemented in translation module?
I don't think we want to name this variable $language, since its not a language object. We use $language exclusively for language objects in Drupal 8. Name it $setting or $multilingual_setting or $node_type_language_setting IMHO :)
Make sure to include dots at end of descriptions. 3 dots missing here.
I don't understand why you need this here. It would be returned later anyway(?). Also baking this in looks bad for when more special languages come to fruition.
In light of my above comment, these would be $language_content, right?
Also you can avoid repeating the same code by moving the 'user_default' case above the 'current' case and falling over if the condition did not pass.
I think we agreed above in the discussion that this would hide the widget too in core (basically make #type => value). Contrib could show it selectively if they want to, no? As it is this is a regression since it would show language fields on single language sites for example.
I don't understand the comment now that the condition was removed from below?!
Why do you need to change these?
Note: this will fail once you actually remove the field for locked languages again. Needs to be set back as it was before.
The comment is not accurate anymore? There does not seem to be such options in the patch. Also why would you do this? If the node type was language locked, you unlock it??!? When the translation module in uninstalled?
PHPdoc function comment summaries should be on one line only. Further explanation should go after an empty line and can be of any length.
Also I don't get the logic. If the language is locked, translation would not be possible in any case right? Regardless of what the type is locked to.
Also I don't get the error message. "no default language is None"?!
Comment #142
andypostWhat's about SLS?
+ global $language_interface;
Probably this should be
drupal_container()->get(LANGUAGE_TYPE_INTERFACE);
Comment #143
ArtusamakUnassigning myself from this task for now, i don't have time to work on it. :(
Comment #144
kbasarab CreditAttribution: kbasarab commentedGonna look into this rerolling this. Seems like right now we just need to take #141 comments into consideratoin and reoll/incorporate that into #139.
Comment #145
Gábor Hojtsy@kbasarab: Yes, looking for your updates, thanks.
Comment #146
kbasarab CreditAttribution: kbasarab commentedPosting strictly the reroll to make sure tests pass before jumping into Gábor's changes.
Comment #147
kbasarab CreditAttribution: kbasarab commentedDidn't change everything that you mentioned Gábor just a few of the main issues/styles. Let most of the questioning ones for some discussion.
Up to date in the reroll now though with the clean patch above and then patch here with some of the changes. Unassigning myself now until we have more definite ideas of changes.
Comment #149
Gábor Hojtsy@kbasarab: can you make sure it passes tests? Given that nobody had secod opinions in over two weeks and that this would be a cornerstone of moving forward with language support on entities, it would be good to move ahead instead of pretending some discussion is happening here.
Comment #150
kbasarab CreditAttribution: kbasarab commented@Gábor Yeah. Not sure why that didn't pass testing. But I"ll look into it and get it passing.
Comment #151
Gábor HojtsyOk, so this was not a really big change. The comment language assignment was checking a variable not available anymore, so it never inherited the node language which made the tests obviously fail. Can you help with fixing the rest of the issues? This has been close to being committed several times, it should not need to endure this much pain if we stretch it a bit and get it in sooner than later. The more we tinker with it the more Drupal core changes and the less useful our work becomes.
Comment #152
kbasarab CreditAttribution: kbasarab commentedI haven't been able to get tests to run locally the past few days locally so I may need to do another reinstall of DB. Keep getting lots of AJAX errors whenever trying to run tests locally. Here is some changes though that we'll play roulette with to see if they pass. Interdiff is from #151 to #152.
Comment #153
kbasarab CreditAttribution: kbasarab commentedOops, uploaded wrong interdiff.
Comment #155
kbasarab CreditAttribution: kbasarab commentedSo my diffs are screwed up here. I think I submitted the wrong piece. What I get for rushing before an event. I'll circle back to this later on tonight or tomorrow.
Comment #156
kbasarab CreditAttribution: kbasarab commentedLets try this one.
Comment #158
kbasarab CreditAttribution: kbasarab commentedJust another test to see where I'm at. I had made an edit to WebTestBase.php last time and am not sure I should have done that. Just interested to see what failures this one gets if I revert just that one piece:
Comment #160
kbasarab CreditAttribution: kbasarab commentedMain change here is changing operator in webtestbase.php and remove change I had made in an earlier commit:
Comment #161
kbasarab CreditAttribution: kbasarab commentedHelps to attach the patch.
Comment #163
kbasarab CreditAttribution: kbasarab commentedAnd again. Rerolled and its passed all the tests localled except for a page caching one which was failing on core 8.x for me as well.
Comment #164
kbasarab CreditAttribution: kbasarab commentedA pass. Could someone review again to ensure all the style changes and everything looks right on this? I've been looking through the code so much I'm not sure which end is up anymore.
Comment #165
Gábor HojtsyThanks again for working on this patch. Here is my review of the current patch:
We don't need to change the last t()-ed string, it is just a confirmation message in the test results, does not need to be identical to what was looked for (1st string).
There are various other LANGUAGE_* constants now that denote special languages. Those should be supported here too.
"User's preferred language" would be a better name. When a user is edited it is not presented as their "default" language, but rather as their "preferred".
I don't know how often I said this above, but it feels like quite a few times :) Let's not make this "*locked* and appear" but make it *hidden* (locked and not appear).
At least make and explain the behavior like that. I'm not 100% sure "hidden_" is a good replacement for "locked_" in the variable names, but it likely is.
I looked but could not find in this patch now the place where this locked feature is enforced.
You wanted to assign the drupal_container() return value to $language_interface locally?
Also, the UI says it would be the **content** language, not the UI language. So use LANGUAGE_TYPE_CONTENT!
Why not hide this with #states when not valid (additionally to the error message on validation)?
If the based language is of any other special languages (see above), that would also not allow it to be translatable.
Comment #166
kbasarab CreditAttribution: kbasarab commentedHaven't had a change to work on this yet but could you elaborate some on this part. Without dealing with this entire issue though I've still kinda missed what the objective of this part is:
Comment #167
kbasarab CreditAttribution: kbasarab commentedI'm not sure what the intention was here. I did change it to LANGUAGE_TYPE_CONTENT though.
Comment #168
RobLoachYou actually probably don't even need to call this as the object will be initialized the first time the ->get() is called. If you just remove that line of code, the tests should still pass.
Comment #169
kbasarab CreditAttribution: kbasarab commentedOk. Thanks Rob. One other thing I meant to ask about was the form #state in:
Since we added support for the other constants and wanting those not to trigger this field can we do a form state invisibile on an or value? Seemed like from what I researching there is a patch for that but not in core yet.
Comment #170
Gábor Hojtsy@kbasarab: I think we'd "only" need to have three values, so you'd only need to repeat the :input condition array 3 times, which might be fine here. If you are interested in working on the *or* condition for states, that also sounds cool, but we've been working on this for *long* and we'd really need to get this in to generalize to entities sooner than later. I hoped we can make this quick and move on to the more general case after (so we don't also need to migrate all settings and figure out form integration and settings integration for other entities, but the longer this lasts, the more it makes sense not to limit its scope, and the harder it will get to any change in :/)
Comment #171
kbasarab CreditAttribution: kbasarab commentedYeah, Definitely am not wanting to expand scope. Just want to get this done and ready. The issue I saw though is when I duplicated the input condition array it did not work for states. So the only one that actually becomes invisible is the option for none.
If I tried duplicating the input condition three times it would overwrite the array key each time:
So in the example above only the N/A (zxx) would become invisibile via #states. If I make 'value' an array it doesn't work at all as #states doesn't support this.
I can just leave it as is though and have "None" become invisible and the Multiple or N/A continue to show.
I'll reroll today with Rob's change included and tested and get it back ready for another review.
Comment #172
Gábor HojtsyRight, right, it overwrites it. I think it is not good if we don't hide it when it does not make sense to show. So I don't think just hiding it for 'und' is a good intermediate step. Let's try to figure out some clever solution. We can put in a little custom JS I think to the same effect. There are tricks like the regex states trick from http://evolvingweb.ca/story/extending-form-api-states-regular-expressions, but they are not core-worthy as-is. :/
Comment #173
Gábor HojtsyIn other words, I think we should have a few lines of custom JS and note there that it should be refactored once #states is more versatile.
Comment #174
kbasarab CreditAttribution: kbasarab commentedThis adds some jQuery to the form for removing items and rolls in Rob Loach's change.
Comment #175
Schnitzel CreditAttribution: Schnitzel commentednew patch, letting the testbot doing the hard work and run all test, because some of them might fail.
Comment #177
Schnitzel CreditAttribution: Schnitzel commentedpatch was wrong way around, reroll
Comment #179
Schnitzel CreditAttribution: Schnitzel commentedso forgot to adapt some more tests.
Changelog for this new patch, thanks for @LoMo to help me on this one.
Adding JavaScript Tag for @nod_ because we definitely need some review of the translation.js file.
Comment #181
Schnitzel CreditAttribution: Schnitzel commentedoh thanks testbot :)
Found a bug in the node_update_8003 upgrade script, it does not unhide the language selector if translation was enabled before, which needs to be done if translation should be possible
Comment #182
Schnitzel CreditAttribution: Schnitzel commentedComment #184
Schnitzel CreditAttribution: Schnitzel commentedohh PSR-0 patches broke it, reroll
Comment #185
Schnitzel CreditAttribution: Schnitzel commentedComment #187
Schnitzel CreditAttribution: Schnitzel commentedrerolled, because another PSR-0 came into my way and it had some strange crap which shouldnt be there.
Comment #188
RobLoachLooking very nice! It would be great to take a closer look to see if we could accomplish what the JavaScript does with States. Might need some closer looking into. Leaving needs review so other people could have a quick look.
Use strict?
Would be good to have a newline here to avoid the git warnings.
Comment #189
nod_Use strict. https://drupal.org/node/1570578
That's true that #states might be the way to go for translate.js
Comment #190
Schnitzel CreditAttribution: Schnitzel commentedSo here is a new patch which fixxes the new line, thx @Rob Loach.
@nod_
will be okay for you if we get this patch in and we fix the translate.js JS review in a follow up?
It's a pretty important patch to have in and in my opinion the JS can also be done later :)) and of course will not put preasure on you
Comment #191
Schnitzel CreditAttribution: Schnitzel commentedreroll because of PSR-0 commits
Comment #192
nod_I'd rather not but I don't want to hold back a big major patch just for that. I will hunt you down and make you review and RTBC the follow-up patch. Otherwise the clean up will never happen.
Be prepared :)
Comment #193
Schnitzel CreditAttribution: Schnitzel commented#191: 258785-191.patch queued for re-testing.
Comment #195
Schnitzel CreditAttribution: Schnitzel commentedreroll because #1452188: New UI for string translation
Comment #196
Schnitzel CreditAttribution: Schnitzel commentedComment #197
nod_JS is fine for me like that, it should be changed overall as a follow-up of #1574470: Selectors clean-up.
Comment #198
Gábor HojtsyYou are not using this code anymore. It was in an earlier version of the patch that you used it, but not anymore.
I think we do links "European style" (do not include the sentence ending dot) usually. Just the text :)
Sounds like this would not include the text from the select box, just the checkbox.
Inital => Initial
Whitespace issues. Too much space.
Use single quotes.
Is this not done yet?!?
Why is translation enabled still 2 and not TRUE/FALSE in the new code? For brand new sites it sounds like it would be a checkbox, so only updated sites get 2??!
No brackets for return type I think(?)
How is that we just magically get the $node now, and did not do before?!
Let's make the comment human readable :) Include dot at the end.
The first line is pretty convoluted, and definitely does not need to be a ternary operators there, the value itself will be TRUE or FALSE as needed without the ternary :) Could be dramatically shortened with an in_array() equivalent.
Also, $language_default is a misleading name, let's have a better one. We have an API function for this in the language_list() extension patch at #1471432: Rework language_list(), let people use more special languages, so we may want to add a TODO here to use that if this one is committed earlier.
Comment #199
Schnitzel CreditAttribution: Schnitzel commentedImplemented Feedback of @Gabor
Changelog
Comment #200
Schnitzel CreditAttribution: Schnitzel commentedComment #201
Gábor HojtsyOnly found two minor issues now.
phpdoc for functions should be on one line.
dot missing at end of line.
Comment #202
Schnitzel CreditAttribution: Schnitzel commentedfixxed issues found by @Gabor
also found some other Codestyle issues and better explanation of "Translation is not supported"
Comment #203
Gábor HojtsyTypos / code style problems in the interdiff still.
@todo (not uppercase) and comitted (two t).
The solution is not to make it longer unfortunately but to make a shorter initial sentence and write the longer explanation in a second sentence, separating the two by a newline.
comitted
Comment #204
Schnitzel CreditAttribution: Schnitzel commentedfixed!
Comment #205
svendecabooterI was testing this earlier, and most of the feedback I listed seems fixed in #199 and #202 now.
Below still some remarks:
* Under the select list the description says "Explanation of the language options is found on the languages list page."
When clicking the link I see no documentation at all referring to these options. Is this part of another patch that hasn't landed yet?
It is quite misleading to expect more information, when you just get redirected to a page with a list of languages...
* I think the two checkboxes could use a small description text to make more clear what the effect of (un)checking them will be.
Comment #206
Gábor Hojtsy@sven: yes, the language list patch from #1471432: Rework language_list(), let people use more special languages adds info on those special languages. We can remove the link here, but we expect both this one and that one to hopefully be committed this week, so it seems logical to keep that in mind, instead of messing with followups for them. For the checkboxes, the question is if we can give you real value with more description. We had @Bojhan review this earlier, maybe need to have 1-2 more people to figure out if the options were clear or not. Can we do this sooner than later (as in *now*?).
Comment #207
Schnitzel CreditAttribution: Schnitzel commentedYes, this will be way better if #1471432: Rework language_list(), let people use more special languages has landed
Any ideas what you would write? We tried to make it as short as possible and as logical as possible
Comment #208
Schnitzel CreditAttribution: Schnitzel commentedOkay, made some usability reviews with 3 people here at the #d8mi sprint.
Overall all of them could tell me that:
"Hide language selector" is for not allowing the author of a node to change the language
"Enable translation" enables the possibility to translate the node
So basically we don't need more explanation. But what caused the most problems are the new three special languages in D8, but which is not the topic of this patch.
Comment #209
Gábor HojtsyWhich means, this now looks like good to go. :)
Comment #210
webchickNow that #1471432: Rework language_list(), let people use more special languages is in, it sounds like we can make this patch simpler. marking needs work for that.
Comment #211
Schnitzel CreditAttribution: Schnitzel commentedokay, rerolled the patch and resolved all the @todo's
Comment #212
Gábor HojtsyReviewed it again, looks good to me now.
Comment #213
webchickOk, huge thanks to Schnitzel and Gábor for patiently walking me through this issue's functionality.
The patch looks bigger than you would think based on the issue description, but a lot of that is due to a brand new set of tests, as well as the addition of new contextual default values like "User's preferred language" to the options, which should help a lot for various use cases.
We reviewed the usability of this together, and while the list of "not actual languages" in the language list is a bit sad, the only one we could really figure out that could be removed is "Multiple languages," since the semantic difference between that and "Not specified" I don't think is valuable enough to clutter the interface further. But that can completely be a follow-up patch.
So.... committed and pushed to 8.x. Yay! :D
Comment #214
Gábor HojtsyWe should have a changelog entry for this as well as a change notice node. Anybody up for those?
Comment #215
Schnitzel CreditAttribution: Schnitzel commentedwill do one. but give me about 48h =)
Comment #216
Gábor HojtsyCleaning out issue board. Changelog patch. :) Please RTBC if looks good.
Added change notice at http://drupal.org/node/1649382, should hopefully be good.
Comment #217
Kristen PolLooks good to me!
Comment #218
webchickCommitted and pushed the CHANGELOG.txt to 8.x. Thanks!
Comment #219
Gábor HojtsySuperb, thanks all.
Comment #220
Gábor HojtsyComment #222
andypostFollow-up #1809816: Drop remains of landcode in favour of language element
Comment #222.0
andypostcomment link to #116