Here it comes! What we add here:

- A language field to nodes (mysql and postgres schema updated, upgrade path included).
- The language field is empty by default (which means a node is "language neutral" == not language sensitive).
- Whether a node type can have language settings depends on a content type setting. We discussed this briefly with Dries, and he said maybe we should try a permission, not a node type setting. We figured it is better to have a node type level setting, so types like 'profiles as nodes' have no language field to disturb the user. This is also important to ensure that different translation methods can kick in, which might or might not have a concept of a 'node level language'. Like polls can collect votes in the same node, and can have the text field translated with an 'in-node method' (not provided by Drupal core), thus having no concept of a node language there, so no reason to disturb editors with a language field. Basically this is an extension point.
- Once you have language enabled a node type, you can set the languauge of nodes in that type.
- The admin overview screen for content is updated with a language filter and a language column which is (like on the path admin screen) only shown if there are nodes in multiple languages, or locale was turned on. It does not disturb those who are not interested in node languages.

This was implemented by Jose A Reyero and refined by myself. Some stuff which is included in the patch, but is also possible to have standalone (although so small changes :)

- Content filter indicator titles were broken in Drupal due to some filter options being unset() before the title was read out of them. This patch fixes that issue.
- node_form() was broken, not allowing prefilling of the node form is a new node is being submitted and we fixed that as well as consolidated similar code into one block
- There are really small path language improvements included, which were hard to decouple, so I submit in the hopes that it does not really disturb anyone

This is a really slim patch, so we would welcome reviews to approach core with the node translation module we are working on :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

FileSize
93.92 KB

Here is a screenshot montage of the interface changes.

kbahey’s picture

Nice work, and an important step for i18n in core.

What about node_revisions though? Should we store the language there as well, so in case it is changed the old revisions would be displayed correctly?

Gábor Hojtsy’s picture

@kbahey: yes, I forgot to point out that we are not having revision support for the 'language' property... I have nothing against having that revisioned though

Dries’s picture

Patch looks good but ...

-    $path_language = isset($options['language']) ? $options['language'] : $language;
+    $path_language = (isset($options['language']) && is_object($options['language'])) ? $options['language'] : $language;

Shouldn't $options['language'] always be an object?

+        '#description' => t('Path aliases set for specific languages override aliases set for all languages.'),

This description might be problematic for newbies. I think we need to be more verbose/helpful here.

+          '#description' => t('Enable multilingual support for this content type. If enabled, a language field will be added to the editing form, if disabled, new nodes are created as language neutral. Existing nodes will not be affected by changing this opion.'),

* 'opion' should be 'option'

* 'a language field' - 'a language selection field'?

* Explain where to configure the languages?

* Use 'post' instead of 'node'? And 'content type' instead of 'node type'?

* Is the term 'language neutral' intuitive? Does that mean I can write in any language? What is the practical value of this? Maybe write 'new nodes are created as language neutral, meaning that ...' I'm pretty sure that my dad would understand the words 'language neutral' but that he wouldn't be able to map that onto practical guidelines.

Dries’s picture

In addition to the cosmetic changes comments, I've one other gripe: the language neutral thing is potentially confusing.

Take Drupal.org for example. We might want to translate some book pages to different languages, but not forum topics. So we'd have to configure forum topics to be 'language neutral'.

However, by convention, all drupal.org forum topics are in English. So, when I'd search for 'English', none of the forum topics would show up which looks wrong and confusing.

So what I'd want to do is: disable multilingual support but default the language to 'English' rather than to 'language neutral'.

Why?

If not, it would make for confusing filter behavior. Remember that the person searching for the content (filtering the content) might not be the person who setup the forum and its multilingual configuration. The average content editor might not have a clue about the fact that forums are language neutral. If they are written in English, he or she expects these to be classified as English.

And if we take this one step further. Often times, a forum has sub-forums for different languages. In this case, I want even more complex workflow support. When someone posts a forum topic to the Spanish support forum, I want that to be marked 'Spanish'. When someone posts something to the English support forum, I want that to be marked 'English'. But I don't want multilingual support enabled because I don't intend to translate forum topics.

Maybe I'm taking this to far in one step, but it seems sloppy not to categorize English content as English because I've chosen to disable multilingual support.

It seems to me that associating a language to a node is a categorization. And categorization should be independent of multi-lingual support.

Another example, on my personal weblog, I might want to blog in English or in Dutch or in French. I don't intent to translate my blog entries, but I'd still want to associate the correct language with them, not?

Gábor Hojtsy’s picture

@Dries:

1. $options['language'] might be an object by documentation. It is passed in my custom modules, whoever developed them. We can pretend that it is an object, and let PHP throw errors later if that third party programmer was mistaken. Or we can try to avoid that. This is a question of sticking to the documentation saying that it is an object, or protecting us from getting a PHP error.

2. Path aliases: sure.

3. Post, content, etc: sure. Lanugage neutral: see 4.

4. Well, the whole point of this particular feature is to support the use case of your blog :) So you can submit nodes in whatever languages. There is no obligation to translate those nodes. There is no translation implication here, we are just associating a language to a node (or mark a node as language independent - maybe this is better then language neutral), nothing else. The practical use of language independence is for instance for nodes where you are not interested in knowing the language: like aggregated content from a multilanguage blog, where there is no way to get the details of what language that rss item was in. Or for nodes where you have no reason to attach a language mark to, like image nodes (created by image module) of your photos. Unless you provide something for the node, which is language dependant (like a meaningful title), that node is effectively language independent.

We are in the classic problem of 'core provides something which is extensible, and we need to document it but don't know about how contrib stuff will extend that'. The 'multilanguage support' switch on content types is just about requesting a language dropdown on that content type or not. This does not mean a content type will surely not have a language associated. It is very easy to write a form_alter() to add a 'value' type of language field to your forum nodes, so a preset language will get saved for your forum. It is somewhat more complicated to code a forum group level language setting enforcement module, but it is not really hard. Our setting only means that *by default*, if nothing else is installed, new nodes will get created as language independent. We don't know about various contribs extending that, but they can also form alter this description, so they can fix whatever is in here by default.

The question is if we should go farther and support stuff, like 'Always relate this content type with this language'? Or how far should we go here? (Our aim was simplicity with extensibility).

Dries’s picture

The question is if we should go farther and support stuff, like 'Always relate this content type with this language'? Or how far should we go here? (Our aim was simplicity with extensibility).

I think that, as a rule, all content should have a language associated with it. The only exception would be nodes that have no regular body and no regular title. Images nodes without titles, for example. However, image nodes with titles, should have a language associated them. Otherwise, the administration UI is going to be confusing. The vast majority of nodes, should have a language.

Therefore, I think it makes sense to make it automatically assign a language if I don't want a selection menu to be shown. Maybe it should be: "If disabled, the default language (English) will be assigned to this post." instead of "If disabled, the post will be language neutral."? For the drupal.org forum topic use case, this would make perfect sense and a lot less confusing when using the content filters on the administration page.

Of course, this use case would fail for 'image nodes without a title' but I'd think that nodes that are _truly_ language neutral (i.e. not even a title) are less common than an English only forums, for example.

Gábor Hojtsy’s picture

Well, all right. A possible problem here might be that when you enable locale module, all of a sudden, all your new nodes are added as being in English (I bet this will be the default), while all your older nodes are language neutral still.

Dries’s picture

True, this might be a bit awkward. Let's see what the others have to say about this?

Dries’s picture

I think that with a little bit more control about the default behavior, we have a winner. ;-)

Dries’s picture

One more question: how does this translate to other parts of Drupal? Will we have a language selection for blocks too? Will we have a language selection for taxonomy terms? Is there a bigger picture we should be aware of. Just curious. :-)

Gábor Hojtsy’s picture

Dries, most of the people moving from the i18n module suite to localizer, and those starting to use localizer express that *not* having different taxonomies, menu trees and such per languages is a plus. So as far as I see the future for Drupal 6 right now is a (contrib replaceable) string based translation mechanism for menus and taxonomies in. Blocks are still a question. This string based translation mechanism will be replaceable with some contrib functionality (just as the node-node relation based content translation will be replaceable).

Different goals need different solutions as you often note :) Taxonomies and menus are not nodes because they have different needs and they do have different needs with languages too.

profix898’s picture

I'm currently using i18n for content translation and as far as I can tell, a 'language neutral' option is needed. As an alternative you could allow multiple languages assigned to a node, but 'language neutral' actually means the content is written in any language.
Take a site with 2 languages - for example, English and German - Content written for english speaking visitors is marked as english, and german context is marked german. The user decides what content is displayed by clicking a flag in the 'language switcher' block (or the language is detected based on the url or browser settings). However what if you want content to be displayed to all users, thats were 'language neutral' enters the stage. The question is, why should some content be visible to all users. Well, many/most german users can also read english content. So for certain nodes, that are only available in english, it makes a lot of sense to make them available for german users as well. (But it is not necessarily true the other way round.) However this is not possible without a 'language neutral option' or an option to assign multiple languages to nodes.

Gábor Hojtsy’s picture

@profix898: You are cheating with the language properties of a node because your listing methods are not adequately implemented to support the display of certain nodes when translations are not available. This is not a reason to leave cheating options in the system, but a reason to improve on the selection functionality. That said, we are not saying we remove 'language neutral' node functionality, just that it will only be used when explicitly selected (it is still a very valid solution for node based aggregators for example, where language of nodes is not actually known).

chx’s picture

"This is a question of sticking to the documentation saying that it is an object, or protecting us from getting a PHP error." stick to the documentation. I thought that we do not babysit broken code because it leads unneeded code bloat at the calling point.

Gábor Hojtsy’s picture

FileSize
15.09 KB

OK, updated patch which adresses most concerns:

- removed is_object() as Dries and chx noted
- changed path alias language description to be slightly cleaner
- changed node language description to be more descriptive, linking in the list of langauges
- changed default behavior to assign the default language (but keep node language if already set, thus allowing some contrib module to act there and provide automated language assignments for specific nodes, such as envisioned by Dries in his multilanguage forum example)
- rerolled patch against HEAD, where the filter title bug was fixed differently, so adapt to that solution
- fixed a t() misuse bug in the filtering code to allow for extractor to pick up the strings

NOT addressed:

- "Language neutral" is still "language neutral", noone said "language independent" or some other term would be better.
- The language property of nodes is not revisioned. I am not sure about the use care where we need it (unless you modify a node from language neutral to having a language). Should we version the node language?

Please review! We have a lot of stuff in the queue, which depends on this (as well as complements this with translation of other Drupal objects), which would be nice to get accepted!

Dries’s picture

For me this patch looks ready. I've no additional comments and my previous concerns have properly been taken care of. The next person that successfully tested/reviewed this patch, can set it RTBC if he/she wants to. Good job.

Gábor Hojtsy’s picture

FileSize
15.09 KB

Doh, a closing parenthesis was missing. Applied my previos patch to a fresh HEAD checkout, tested and that turned out.
Please review!

Jose Reyero’s picture

The patch looks fine, applies fine, works fine.

Just one small detail. The content type settings help text reads: "If disabled, new posts are saved with the default language.", which is not happening.

I'd say we can just fix this text, or the code...

Gábor Hojtsy’s picture

FileSize
15.04 KB

Oh, well. Changed the check to look for the missing nid, so new nodes are set with the default language properly.
Thanks for testing!

Jose Reyero’s picture

Status: Needs review » Reviewed & tested by the community

Yes, this one works completely fine.

I think it's ready

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Spent 20 minutes testing this and it works! Committed. Thanks.

Suuch’s picture

Category: task » feature

Great to see this in core. We're quite reliant on the i18n module.
Another approach to language selection for nodes we've implemented (in 4.7.x) is simply to think of it as a taxonomy option where an admin interface allows the user to specify a taxonomy-to-language mapping. It even plays nicely with i18n (where installed) since on hook_nodeapi("load", ...) we set the node->language equal to the locale's ISO.

The main advantage of doing this for us was to be able to simply assign language fields without changing Drupal core (coupled with the fact that i18n's language assignment didn't always play nicely with other installed modules). The other virtues are inherited from locale/taxonomy/views modules.

Anonymous’s picture

Status: Fixed » Closed (fixed)