Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Status: Active » Closed (works as designed)

It 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.

Stefan Nagtegaal’s picture

Status: Closed (works as designed) » Active

You 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)

Stefan Nagtegaal’s picture

Or - 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.

Gábor Hojtsy’s picture

Locale 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.

killes@www.drop.org’s picture

If 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.

xmacinfo’s picture

My 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.

dpearcefl’s picture

Sounds like a UI type question. Is anyone interesting in pursuing this in D8?

Gábor Hojtsy’s picture

Version: 6.x-dev » 8.x-dev

Not 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.

sun’s picture

Title: "Language" column in the admin/content/node table should not be visible if "content translation" module not enabled » Hide "Language" column in content overview table if only one language is enabled
Component: node system » node.module
Category: bug » task
Issue tags: +D8MI

Summarizing all the arguments in this issue leads to this proper issue title.

clemens.tolboom’s picture

We still have a Language neutral language. Screenshot is from a D8 install with only Dutch as a language.

hide-language-column-if-only-one-language.png

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

clemens.tolboom’s picture

Status: Active » Needs review
FileSize
748 bytes

The comments around the multilanguage determination is a little weird.

  // Enable language column if translation module is enabled or if we have any
  // node with language.
  $multilanguage = (module_exists('translation') || db_query_range("SELECT 1 FROM {node} WHERE language <> :language", 0, 1, array(':language' => LANGUAGE_NONE))->fetchField());

What if we have translation enabled but still have 1 language enabled?

Attached patch adds more confusion as that count the enabled languages.

Gábor Hojtsy’s picture

@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.

clemens.tolboom’s picture

I 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?

Gábor Hojtsy’s picture

Issue tags: +language-content

Tagging for the content handling leg of D8MI.

Gábor Hojtsy’s picture

- 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.

Anonymous’s picture

I 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.

xmacinfo’s picture

@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.

Gábor Hojtsy’s picture

@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?

clemens.tolboom’s picture

I '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.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

@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.

clemens.tolboom’s picture

Assigned: Unassigned » clemens.tolboom
clemens.tolboom’s picture

Args ... I cannot reproduce the screenshot from #5

I now have Unknown () instead of Language neutral

DEST=drupal.d8
OPTIONS=--yes

drush $OPTIONS @$DEST sql-drop
drush $OPTIONS @$DEST site-install

drush $OPTIONS @$DEST pm-enable language locale
drush $OPTIONS @$DEST pm-enable devel_generate

drush $OPTIONS @$DEST vset node_type_language_article 1
drush $OPTIONS @$DEST --kill genc 10 0

drush $OPTIONS @$DEST uli
clemens.tolboom’s picture

Patch 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)'

clemens.tolboom’s picture

Status: Needs work » Needs review
Gábor Hojtsy’s picture

Status: Needs review » Needs work

Quick 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.

tstoeckler’s picture

I 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?

clemens.tolboom’s picture

Status: Needs work » Needs review
FileSize
2.27 KB

Removed $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 :)

clemens.tolboom’s picture

@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_

Lars Toomre’s picture

Status: Needs review » Needs work

Background: 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.

Gábor Hojtsy’s picture

@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.

Lars Toomre’s picture

Gabor: 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.)

clemens.tolboom’s picture

@Lars Toomre

I don't think we should decide on a page based set what to display.

tnx for the review

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,26 @@ function node_admin_content($form, $form_state) {
+ * Decide we are in multilanguage context.

#29
a) One line header should start with an active verb, like "Checks".

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,26 @@ function node_admin_content($form, $form_state) {
+ * @see node_filter_form()
+ * @see node_admin_nodes()

#29
b) @see directives should follow the @return directive with a blank line in between.

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,26 @@ function node_admin_content($form, $form_state) {
+ * @return
+ *   TRUE when having more than 1 language in our nodes table.
+ */

#29
c) I believe the current practice is provide type hinting with return directives. Hence, I believe it should be '@return bool'.

clemens.tolboom’s picture

Status: Needs work » Needs review
FileSize
2.28 KB

I change all from #29 (and rephrased in #32)

The active verbs thingy is for the english die hards.

tstoeckler’s picture

Looks 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.

Lars Toomre’s picture

Sorry 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.

clemens.tolboom’s picture

Assigned: clemens.tolboom » Unassigned
Status: Needs review » Needs work

@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.

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,27 @@ function node_admin_content($form, $form_state) {
+ * Decides we are in multilanguage context.

Needs a rephrase according to @Lars Toomre #29

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,27 @@ function node_admin_content($form, $form_state) {
+ *

Remove whiteline

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,27 @@ function node_admin_content($form, $form_state) {
+function node_is_multilanguage() {

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'

Lars Toomre’s picture

+ * Decides we are in multilanguage context.

"* Determines whether multiple languages currently are in use." could be used instead for the first line of that docblock.

Gábor Hojtsy’s picture

Issue tags: +sprint

Lars' text suggestion looks good. Also elevating to sprint, should have been on my sprint summary so adding there too :)

Gábor Hojtsy’s picture

On 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.

andypost’s picture

Status: Needs work » Needs review

In 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

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,27 @@ function node_admin_content($form, $form_state) {
+function node_is_multilanguage() {

node - means context of the sigle node, this would cause more errors and misreadings about current node is has language or not

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,27 @@ function node_admin_content($form, $form_state) {
+  if (!isset($multilanguage)) {
+    $multilanguage = count(db_query("SELECT DISTINCT language FROM {node}")->fetchAll()) > 1;
+  }

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

Gábor Hojtsy’s picture

@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?

andypost’s picture

@Gábor Hojtsy sure, it's what I'm talking about

clemens.tolboom’s picture

I changed applied comments from #36 #37 and #39

andypost’s picture

+++ b/core/modules/node/node.admin.inc
@@ -395,6 +395,26 @@ function node_admin_content($form, $form_state) {
+    $multilanguage = count(db_query("SELECT DISTINCT langcode FROM {node}")->fetchAll()) > 1;

this will not pass performance gate

clemens.tolboom’s picture

Status: Needs review » Needs work
Issue tags: +d8docs

@andypost Can you please elaborate on that gate. Preferably @ http://drupal.org/node/1280562 which is [Powered by #1115636: Issue Macros and Templates]

clemens.tolboom’s picture

Issue tags: -d8docs

(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

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
2.43 KB

Instead of querying the database, we can base the occurrence of multiple languages upon the Multilingual setting of node types.

Gábor Hojtsy’s picture

This 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.

Sutharsan’s picture

Currently the Language column is shown when the Language module is enabled or if any node with a language exists.

  • #15 shows the Language column when the Language module is enabled. Even when only a single language is active.
  • #23 shows the Language column based on the data in the full node table. This hides the column if no content in a second language has been added yet. The full node table is queried which is not good for performance.
  • #47 shows the Language column based if the 'Multilingual support' setting of any content type is enabled. This hides the column if this setting is turned off after content is created in different languages. This is in line with hiding the Language selector in the node form.
  • A new option is to show the column if multiple languages are enabled. i.e. using the language_mutilingual() function.

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.

Status: Needs review » Needs work

The last submitted patch, language-column-filter-158803-49.patch, failed testing.

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
2.32 KB

Apparently I did not pull before making the patch :( Lets try again.

andypost’s picture

I think we should add a simple functional test for language_name() to check the "Unknown" result

Patch looks RTBC

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Yeah, 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.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Looks good to me. Committed/pushed to 8.x.

Gábor Hojtsy’s picture

Issue tags: -sprint

Superb, thank you all!

Status: Fixed » Closed (fixed)
Issue tags: -D8MI, -language-content

Automatically closed -- issue fixed for 2 weeks with no activity.