Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Currently, it is visible even if you only enable locale.module.
Currently, it is visible even if you only enable locale.module.
Comments
Comment #1
Gábor HojtsyIt should be enabled! You can have multilanguage content on your site without ever translating any of them. Think a blog site where you post German and English blog posts, but never translate any of them (because you have one-off posts). Drupal 6 supports associating language information to nodes and associating nodes together as being translations of the same content. These two features are different.
Comment #2
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commentedYou can't be serious about this I hope.
If I only want to translate the UI of Drupal 6 (locale.module), why would I want to see all the fuzz of node translation possibilities (translation.module)?
Re-opening so this could be discussed a little further, because or i'm completely missing the point, or not expressing myself very clear. (Maybe even both, perhaps)
Comment #3
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commentedOr - better perhaps - check if the language added with the locale module == 1, then do not display all the node translation checkboxes, dropdownboxes, table cells, whatever.
if Goba agrees, I'll try to make patch somehow. But I really do not want to see this, unless absolutely nessecary. admin/node is holding enough information/options already. Useless information would give us no good.
Comment #4
Gábor HojtsyLocale module provides:
- interface language features
- node language association
It *does not* provide content translation! Stefan, if you only enable locale.module, you don't get content translation features, dropdowns, checkboxes, or anything else. You get no content translation stuff.
Then again, you can set node language association on a per node type basis, and this is turned off by default on all node types. So by turning on the locale module, the node submission/editing forms do not change a small bit.
So I would welcome if we would talk about what is really happening, not going into misinformed exaggeration.
So what you get is a language column in the node admin screen. On a fresh site, before you turn on locale module, you get nodes saved as being 'language neutral'. Once you turn on locale module, all nodes are saved with the site default language, unless you have the language selector turned on for them, which lets you save them in any other language you select. So with a site having content posted before enabling locale module (or eg. content upgraded from a previous Drupal version), at least two types of language associations will exist: language neutral and the site default language. We can certainly hide this, the question is if this is really what should we do in the cases Drupal tries to cover.
Comment #5
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedIf that's "by design" then the design isn't that well thought out.
Most Drupal sites I've done so far use locale module - even the ones that are all in English. And all sites are in one langauge only. Why is it a good design to bloat the UI of these sites with these settings or extra columns?
IMNSHO you should test if there are more than ony active languages before showing extras like that column.
Comment #6
xmacinfoMy two cents!
My understanding is that bare bones Drupal 6 installations will always have two languages displayed in the language column: "Language Neutral" and "English". So it makes sense to display which nodes are English tagged and which ones are Neutral tagged.
Even for sites that have a single language enabled, like French, this table should dispay nodes that are tagged French (français) and tagged Neutral.
Comment #7
dpearcefl CreditAttribution: dpearcefl commentedSounds like a UI type question. Is anyone interesting in pursuing this in D8?
Comment #8
Gábor HojtsyNot sure if this is still applicable, but I think #540294: Move node language settings from Locale to Node module is where this might be solved.
Comment #9
sunSummarizing all the arguments in this issue leads to this proper issue title.
Comment #10
clemens.tolboomWe still have a Language neutral language. Screenshot is from a D8 install with only Dutch as a language.
Related issues are (just a few):
#198355: how to disable 'language neutral' option for creating new pages?
Blocked by #258785: Provide more flexible settings for initial language on content types
#311158: default node language
Comment #11
clemens.tolboomThe comments around the multilanguage determination is a little weird.
What if we have translation enabled but still have 1 language enabled?
Attached patch adds more confusion as that count the enabled languages.
Comment #12
Gábor Hojtsy@clemens: I think if you have translation module enabled, you are likely to introduce more languages, if not yet done. So it makes sense to expose language for you. Also, you might not have translation module enabled but still have nodes in different languages (via language module), so it would probably make more sense to just make this conditional look at language module and forget about translation module here. A site might have nodes in all kinds of languages and never have translation module enabled. Also, even if you only have one language enabled, you might also save nodes with that language and as language neutral at which point there is a distinction to make.
I think with the current codebase that does not need locale or language module enabled to display basic language information like language names, we can just use the db_query_range() part and remove the module condition altogether.
Comment #13
clemens.tolboomI don't like the LANGUAGE_NONE construct as showed in #10. I expected no language column at all. But that site was done with devel generate.
I somehow expected all content being in Dutch on that test and not some in LANGUAGE_NONE.
Editing a node allows me to select a Language neutral but I don't get that.
So I somehow expected the other way around. When there are nodes with LANGUAGE_NONE we should display the Language column. I expected #1260488: META: Introduce real language APIs to list an issue 'Always set content language to site default language'. Or did I miss an issue?
Comment #14
Gábor HojtsyTagging for the content handling leg of D8MI.
Comment #15
Gábor Hojtsy- The "Language neutral" was recently renamed to "None" to be simpler and easier to understand.
- Indeed nodes are saved with "None" language until you enable language module AND you language enable the node type. Until a node type is language enabled (by these two steps), it will be saved with "None".
I think that makes sense, since you did not language enable them yet, right? Also its pretty hard to make assumptions about your nodes without having language specified. I understand you are advocating that nodes be saved in English until you enable language module *and* enable language support on the node type *and* add another language to be able to select? In my view, having the nodes pre-language saved as language neutral makes it easier to audit and update them proper (+ they can easily not be in English) once you configure/add a language. If we save them with an assumed language that might or might not be true (although I agree it makes a lot more sense for English sites that later want to add a new language, so they don't need to update nodes en masse).
Anyway, all-in-all I think the language column can only have variance if the language module is enabled, since that is the only point where we expose a UI to actually specify it, so regardless of where do we default the nodes, until you enable language module, the language value will not have variance. When you enable language module, it can have variance (even without adding more languages, you can then save nodes as English OR language neutral too). So I think a very easy and logical condition for the filter and column would be to check for language.module being enabled. I understand this goes a bit counter to the original goal of this issue, but enabling language module in fact exposes two language options, None and English so depending on the definition that would be two languages. If we want to be super-fancy, we can check for whether we have at least two languages actually used on nodes directly, which sounds like it would be a group by and that may not be too quick.
Here is a patch which bases the filter and column on language.module only.
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedI always had problems with content editors who didn't understand the "Content Neutral" column and were asking to replace the language in this column with "English".
On the other hand, I agree that Language:None is useful in several cases, so we don't need to save our nodes as English before language module is enabled (but I would like to have an option to bulk update from Language:none to my selected Language, after I enable this module).
Personally, I agree with the logic of patch #15, but I would prefer to hide the column when we have one language enabled, even if we have mixed content (Language"English and Language:None) and show it only if we have at least two languages actually used on nodes directly.
Comment #17
xmacinfo@infowonders: Have a look at https://drupal.org/project/languageassign that lets you bulk update from
“Language:none to my selected Language”
although not available for D8 yet.
Comment #18
Gábor Hojtsy@infowonders: what would people do who purposefully use the single language and the language neutral nodes side by side? (Eg. when starting to build out a site in a language to be expanded to more languages later). They'd get no information or possibility to filter by them?
Comment #19
clemens.tolboomI 'really' don't understand the Language 'None'. When people run the installer then choose the Language for the site. To me that's a statement "My site is in language X" implying "my content has language X" right. So to me LANGUAGE_NONE is 'bogus' ;)
We can only hide the column when all nodes have just one language and that's hard to accomplish when we allow LANGUAGE_NONE.
I disagree with @infowonders to hide even when having Language:None nodes as that hides (debugging) information.
Comment #20
Gábor Hojtsy@clemens: ok, right, well, we can definitely debate how to save new nodes, remember #258785: Provide more flexible settings for initial language on content types was originally opened to protest that nodes were saved in the site default language in D6. I think we should keep discussing that there.
For this issue, looks like our best route is to actually check the data if we have nodes at least in two languages (where one of them can be None). Anybody wants to work on that simple patch? (IMHO do a helper function that is used from the filter setup and the column setup code that would check the number of unique language values in the node table).
I think this issue and #258785: Provide more flexible settings for initial language on content types should be solved independently. We'll have upgraded data anyway that we need to expose if for nothing else, debugging as noted by @clemens.
Comment #21
clemens.tolboomComment #22
clemens.tolboomArgs ... I cannot reproduce the screenshot from #5
I now have Unknown () instead of Language neutral
Comment #23
clemens.tolboomPatch does check for having more than 1 language in the nodes table. When having just 1 language the language filter and columns are hidden on admin/content
We also fixed the display of an unknown langcode to 'Unknown (empty)'
Comment #24
clemens.tolboomComment #25
Gábor HojtsyQuick review. Looks generally good! Notes:
- are we documenting statics now? (I'm new to this).
- dot at the end in last comment missing
- I'm not 100% sure we should name this function _node_... (ie. "private"), other outside modules might very well want to use/know this information, it sounds pretty useful.
Comment #26
tstoecklerI think "Unknown (empty)" is only clear if you know that that usually looks like "Unknown (en)" or "Unknown (de)", so maybe just "Unknown"?
Also
node_multilingual() would be in-line with language_multilingual, no?
Comment #27
clemens.tolboomRemoved $static doc as we do not use that. It could be an improvement for our function docs though.
Added dot.
Made it a public function but that means api change ... I could not find that tag so please add it :)
Comment #28
clemens.tolboom@tstoeckler
The distinction between http://api.drupal.org/api/drupal/core!includes!bootstrap.inc/function/la... and node_is_multilanguage lies in the static behaviour.
We can have the column back after a page load when another user edits a node.
I don't get the meaning of language_multilingual by reading its name but I would for language_is_multilingual.
multilanguage is maybe wrong in name and should be multilingual. But I still prefec the _is_
Comment #29
Lars Toomre CreditAttribution: Lars Toomre commentedBackground: On one D6 site, my client has about 5,000 nodes with only a couple in a non-English language (and maybe 500 language neutral). Using the logic in the existing code, 3 separate languages are identified and hence the language column is always present on admin/node/content. However, the client felt on most pages that column added no value whatsoever (plus he wanted a few others added).
I solved the issue for my client by creating a custom page that mimiced admin/content/node with the following modifications:
1) Get a variable that indicates whether to treat 'language neutral' as a separate language (assume to treat it as 'en').
2) Assume that the language column will be present in constructing table rows
3) In row loop, add language value to local array
4) After constructing rows, reduce local array to unique values and possibly remove language neutral.
5) If count of local languages == 1, remove the language column from $header and $rows.
Perhaps this approach might be useful here?
Regarding the patch in #26, the docblock for node_is_multilanguage() needs work. Specifically,
a) One line header should start with an active verb, like "Checks".
b) @see directives should follow the @return directive with a blank line in between.
c) I believe the current practice is provide type hinting with return directives. Hence, I believe it should be '@return bool'.
Finally, I might suggest a function name like node_collection_languages() which returns an unique array of active languages on the website. From there, one could determine both if there was more than one language (with possible adjustments for neutral) and be useful to contrib modules.
Comment #30
Gábor Hojtsy@Lars: I'm not sure about your algorithm for the language column. If you run a multilingual forum board let's say and all the last 30 nodes are in a language, then the language column would disappear, right? Although you might very well be interested in it. So all in all, I'd not make such assumptions about user needs. Ideally this page would be a VBO view you know which lets you add and remove columns at will and configure them wildly, but that is not really an option here.
Comment #31
Lars Toomre CreditAttribution: Lars Toomre commentedGabor: You are right. If all of the languages on the page are the same, the language column would disappear.
That is what my client wanted. (Or to be more precise, he wanted the column to only appear if a node was in a language other than the primary language, which in this case was English. Language neutral nodes were assumed to be English.)
Comment #32
clemens.tolboom@Lars Toomre
I don't think we should decide on a page based set what to display.
tnx for the review
#29
a) One line header should start with an active verb, like "Checks".
#29
b) @see directives should follow the @return directive with a blank line in between.
#29
c) I believe the current practice is provide type hinting with return directives. Hence, I believe it should be '@return bool'.
Comment #33
clemens.tolboomI change all from #29 (and rephrased in #32)
The active verbs thingy is for the english die hards.
Comment #34
tstoecklerLooks good.
Since we have been renaming functions a lot @Gábor Hojtsy should probably comment on the function name. While I still think node_multilingual() is better, I really couldn't care less.
So not marking RTBC for a final lookover by said Drupal hero. :)
EDIT: Fixing super-weird typo.
Comment #35
Lars Toomre CreditAttribution: Lars Toomre commentedSorry for my lack of clarity @clemens.
The blank line should be after the @return directive (as you have done). There should be no blank line after the @see directives.
While you are correcting that, you might want to adjust the first line of that docblock to be proper English.
Comment #36
clemens.tolboom@Lars Toomre: could you please install dreditor as you can mark lines and provide comment for with a snap :) ... your feedback was great to learn from the D8 coding standards.
As I said in #33 I will not fix that first sentence as I'm not good in active verbs :p
Thus I unassigned the issue for now.
Needs a rephrase according to @Lars Toomre #29
Remove whiteline
Should we name this node_multilingual()?
I prefer node_is_multilingual but that still does not make more sense as we are talking about 'are there more than 1 languages for all our nodes'
Comment #37
Lars Toomre CreditAttribution: Lars Toomre commented"* Determines whether multiple languages currently are in use." could be used instead for the first line of that docblock.
Comment #38
Gábor HojtsyLars' text suggestion looks good. Also elevating to sprint, should have been on my sprint summary so adding there too :)
Comment #39
Gábor HojtsyOn node_is_multilanguage(), Drupal 7 has drupal_multilingual(), Drupal 8 renamed that to language_multilingual(), so along those lines node_multilingual() would make sense. IMHO better than node_is_multilanguage(). node_is_multilingual() would also be a candidate but then we'd need to rename language_multilingual() (again) for consistency to not freak out developers with our inconsistent naming.
Comment #40
andypostIn D7+ we have this page as renderable array so just simple hook will allow you to customize this screen for scrupulous client so let's close this issue. Also having Views+VBO installed is less bad then querying node table.
Suppose having clear settings for node-types will prevent most errors, so better to focus on #258785: Provide more flexible settings for initial language on content types
node - means context of the sigle node, this would cause more errors and misreadings about current node is has language or not
db killer for sites with huge amount of nodes, and just for hiding column from UI?
db_query_range("SELECT 1 FROM {node} WHERE type <> 'und'",0,1) but suppose checking variables is a preferable way
Comment #41
Gábor Hojtsy@andypost: the und query means something very different from the group by query. I.e. With the group by condition, if you only have Russian nodes, the colmn would not show assuming you know about the fact. The und query would show them. There lies the goal of this issue :) we can thoretically optmize this by computing the flag on upgrade and then update it with node saves? Which would only require us to tell if a node in a different langugage from the current being saved exists to update the lfag. Sounds quicker than the group by?
Comment #42
andypost@Gábor Hojtsy sure, it's what I'm talking about
Comment #43
clemens.tolboomI
changedapplied comments from #36 #37 and #39Comment #44
andypostthis will not pass performance gate
Comment #45
clemens.tolboom@andypost Can you please elaborate on that gate. Preferably @ http://drupal.org/node/1280562 which is [Powered by #1115636: Issue Macros and Templates]
Comment #46
clemens.tolboom(I added this one myself but we could use some help over there.)
[Powered by #1115636: Issue Macros and Templates]
Changes that add or modify SQL queries should include: EXPLAIN output, description of indexes added or changed, indication of how often the query is likely to run and under what circumstances. The goal is not to add additional database calls unless absolutely necessary, and to ensure that all queries scale when using large data sets (avoiding scanning large numbers of rows, filesorts, temporary tables etc.)
For more info see http://drupal.org/project/devel / http://dev.mysql.com/doc/refman/5.0/en/explain.html
Comment #47
Sutharsan CreditAttribution: Sutharsan commentedInstead of querying the database, we can base the occurrence of multiple languages upon the Multilingual setting of node types.
Comment #48
Gábor HojtsyThis could be such a simple issue! :) Can we agree on the what we look for as a condition? @Sutharsan's idea seems good to me. Also IMHO in reference to comments from others, it would likely be best to rename to node_multilingual() to rhime with language_mutlilingual() in core.
Comment #49
Sutharsan CreditAttribution: Sutharsan commentedCurrently the Language column is shown when the Language module is enabled or if any node with a language exists.
If Language None is important, only the #15 solution is acceptable. If Language None may be hidden if only one language is enabled, we should use the fourth option. In this issue I can not find arguments for displaying the None in a monolingual site except for debugging. Let's leave debugging to Devel and contrib space.
This patch drops the node_multilingual() function and uses language_multilingual() to show/hide the Language column.
Comment #51
Sutharsan CreditAttribution: Sutharsan commentedApparently I did not pull before making the patch :( Lets try again.
Comment #52
andypostI think we should add a simple functional test for language_name() to check the "Unknown" result
Patch looks RTBC
Comment #53
Gábor HojtsyYeah, ok, the patch looks good. I think we could keep arguing forever as to what to display this column. The form is wrapped in drupal_get_form('node_admin_content', ...), so those who need to add or remove the column will still be able to do so in contrib. And the patch syncs the behavior for the language filter and column which is the most important goal to achieve for consistency, so you don't have the column without being able to filter for it and vice versa.
Comment #54
catchLooks good to me. Committed/pushed to 8.x.
Comment #55
Gábor HojtsySuperb, thank you all!