Allow creating nodes in disabled languages

For the first part, instead of disabling the 'translate' link for disabled languages, we should still allow users to translate nodes into disabled languages. This means that they can translate all their content in advance of enabling the language. So instead we probably need to change the permissions check on the create translation form with the language select enabled.

Cheers,
Stella

I've tested this and it works perfectly, including tests. Nice work!

After reviewing the code and discussing with catch and stella, I think these are two separate questions.

1. language options on node/add

First is the question of what languages should be available on node creation. Currently, only enabled languages are available. This contrasts with the node translation functionality, in which existing nodes can be translated into all languages, not just enabled ones.

Here, it does seem that, for consistency, if we allow translating nodes into disabled languages, it should also be possible to create a node in a disabled language.

It looks like the patch, though, should not be on the translation module, since that will take effect only if translation is enabled, and really we should have consistency between translation and multiple languages without translation. So the patch should be on locale_form_alter() and just add the TRUE argument to locale_language_list().

2. links to translations in disabled languages

The question here is whether links should display to existing translations in disabled languages.

Sites will commonly want to have content available in more languages than the subset available as interface languages. My understanding is that our language enabled/disabled status is primarily for interface language. So I think the answer is, yes, links should display in disabled languages.

Renaming the issue to refer to only the first question. We could open a second issue if we want to pursue the 2nd further.

I think there are some different issues here:

If a language is disabled it should be *disabled* not showing up anywhere besides language admin page.

That said, it may make sense to enable different languages for content and for UI, but don't name them 'disabled', maybe a 3 status (1 - enabled for content, 2 - enabled for UI 3 - Disabled)

Another option may be to set up allowed languages per content types (and also allowing Language neutral or not per content type), that's a feature request we have around fir i18n that may make sense here.

If links exist to create translation in a disabled language at node/n/translate, it should be possible to create such a node. This is my #1 priority for this patch.

Otherwise, I'd be happy with one of the following:
* I can imagine a case whereby the node form language selector is exposed for user-generated content, in which case it may not be desirable to allow content to be created in disabled languages. In this case we could add a permission "translate content into disabled languages" to enable the selection of such language on both the node/n/translate page as well as the select box on the node form. The issue then is that users able to edit such nodes set with disabled languages but without the permission to "translate content into disabled languages", the node will revert to "Language Neutral" when saved.
* Or, we create a middle status as per #6

#3: disabled_languages.patch queued for re-testing.

Catch up to HEAD.

Probably now it's too late to go on with the approaches proposed in #5/#6. Personally I agree with Jose when he says that a disabled language should be actually unavailable. Anyway, given that we cannot (and we couldn't in D6) create content in a disabled language IMO the only viable solution at this stage is hiding disabled languages in the translation overview page. We will always be able to deal with the need of hiding content still being translated through the node status.

I'd suggest to keep this issue for the node links bug and address the other one in #343164: Show only enabled languages on the "translations of ..." page.

You may be able to hide content being translated, but the language still has to be enabled so that it can be selected when creating/editing the content, under your suggestions. Translating any content into a new language will require the language to be enabled, and thus visible from language switching links, which in many cases may not be desirable.

Most multilingual sites I've worked on have launched translated versions of their site all at once, not page by page. The translation workflow will not get easier if the translated content must be specified as "language neutral" until such time the language switcher links should be enabled, and thus the language enabled.

+1 on the patch.

I think we should clarify some aspects before going on with working on a fix. Please follow up on #778528: Define the language switcher's correct behavior.

+++ modules/translation/translation.module
@@ -125,6 +125,10 @@ function translation_form_node_type_form_alter(&$form, &$form_state) {
+      $form['language']['#options'] = array('' => t('Language neutral')) + locale_language_list('name', TRUE);

Should be

$form['language']['#options'] = array(LANGUAGE_NONE => t('Language neutral')) + locale_language_list('name', TRUE);

Powered by Dreditor.

If we go on allowing to create nodes in disabled languages we should fix also http://api.drupal.org/api/function/field_content_languages/7.

Why not having a unpublished option for languages beside enabled/disabled? enabled will be available for all, unpublished only for users with proper permissions, and disabled is simply disabled.

I've seen a similar scenario, where a site owner has 3 languages and added two more hidden languages that are being translated, then he disabled one language because the translator for that language left the job.

Why not having a unpublished option for languages beside enabled/disabled? enabled will be available for all, unpublished only for users with proper permissions, and disabled is simply disabled.

This cannot happen in D7 (it went feature-frozen one year ago) and we must fix this in D7 first.

Just adding this option instead of arguing what should disabled do, this might go into a contrib module, I'm with keeping disabled languages, disabled.

Your solution does not take into account the following from #14:

Most multilingual sites I've worked on have launched translated versions of their site all at once, not page by page.

This case is for small websites that don't have regular new content, anyhow in this case you can translate all the content in 'unpublished' language, then when you are done and ready to launch the site all at once you can toggle the published button for this language. It's a concept taken from nodes, also you can use this extra button in views to see unpublished content (useful for reviewers translators).

Sure, also the approach described in #22 is perfectly valid, but it does not interfere with the proposed solution of allowing to create content in disabled languages. AAMOF language switcher links are allowed only for enabled ones so "disabled" content would be somehow "invisible".

IMO #12 is a viable option. Here is a rerolled patch that fixes http://api.drupal.org/api/function/field_content_languages/7. As pointed out in #343164-1: Show only enabled languages on the "translations of ..." page we also need a way to remove native English form the language list as the language configuration UI does not allow it. As we are in UI freeze the patch introduces a system variable allowing to choose if hide native english from the language list.

+++ includes/bootstrap.inc	28 Sep 2010 11:24:39 -0000
@@ -2386,6 +2386,12 @@ function language_list($field = 'languag
+      if (!$languages['language']['en']->enabled && language_default()->language != 'en' && !variable_get('drupal_native_language_enabled', TRUE)) {

The language default test is useless as disabled languages cannot be set as default. Removed it.

Powered by Dreditor.

The latest patch involves a subtle API change: although field_content_languages() will keep working exaclty as intended, its return value will be different.

Badly needed.

Better comment and variable renamed.

Although badly needed, this is D8 material according to the rules (I had to learn today). It may be backported at a later point in time (though that's unlikely).

What rules?

This must be fixed for D7 ASAP, otherwise the TF UI won't be able to support this use case.

To summarize the issue: currently the node translation page displays a list of languages users can create translations in, including disabled ones, but subsequently when one tries to create a node in a disabled language, he discovers he cannot because disabled languages do not appear in the language selection widget.

This is both an usability flaw and a core misbehavior: if a language is disabled it means we want to work with it, otherwise we could simply uninstall it. A disabled language is not shown in the language switch links so it is virtually "invisible" for end users, even if nodes are not given the unpublished status. This allows to make a whole site translation available at once by simply enabling a previously disabled language.

The only relevant exception to this otherwise sane workflow is native english: as pointed out in #343164: Show only enabled languages on the "translations of ..." page, since it cannot be uninstalled it is always displayed in the translations list, which can be confusing for translators if the site is not meant to present english content or has a custom english language enabled. Since we are in UI freeze, we cannot add an explicit option in the language configuration page to hide native english from the installed languages list. To solve this the patch introduces a system variable that can be set through settings.php.

So far so good. The problem here is that to create a content in a disabled language we need to change http://api.drupal.org/api/function/field_content_languages/7 to return installed languages instead of enabled ones. This sounds like an API change and formally it is, but since here we are allowing disabled content to be created, contrib code calling it (and I sincerely doubt there is any) should keep working exactly as intended. AAMOF code needing a list of enabled languages has always had language_list('enabled') as the primary means to get it. So my point is this should be a harmless API change.

I checked out the whole contrib repo and grepped the HEAD of each project (I know it's not a comprehensive test but it gives us an idea), this is the result:

plach@tittiesandbeer:~/sandbox/drupal$ grep -R field_content_languages .
./translation/translation.module:  $enabled_languages = field_content_languages();
plach@tittiesandbeer:~/sandbox/drupal$

I'm pretty confident that the Translation module maintainers will accept this API change with joy :)

Related issue: #926212: URLs rewritten with disabled languages.

plach and I discussed this in #drupal-contribute.

It didn't originally register with me that it would be desirable to see disabled languages in the language selector, but plach explained that while you're preparing a translation to be active on the site, you need sort of a "draft" mode for the translation, and disabled languages accomplishes this.

So I think the API change here is ok. The only suggestion I had was that the current code stuffs all the languages together which is probably going to be confusing, usability-wise since "French" (which is disabled) would show alongside "English" and "Klingon." So I further suggested adding an <optgroup> here to denote disabled languages so it's clear to the translator. This is a minor UX freeze breakage, but I think it's important to alleviate potential confusion.

Here is a rerolled patch.

Sorry, I missed a couple of ! and so group labels were inverted :(

Agreed w/ catch.

Here it is.

@catch: is this ok now?

Adding to the "before beta" queue as we have small UI and API changes here.

Hoping to have this RTBC'ed again soon enough.

The http://drupal.org/project/translation project at least requires the language system changes of this patch. Since those cannot be really tested without exposing the functionality in core's Translation module, plach took the extra time to implement the necessary changes and tests for it.

Thanks sun!

Actually credits for the tests go to @catch, though.

#40: translation-356036-40.patch queued for re-testing.

Ok, great. That resolves all of my concerns.

Committed to HEAD.

The API change here is small: field_content_languages() now returns all languages, rather than only enabled ones. This is actually just making the function conform to the documentation, so I'm not sure that an announcement to devel is strictly required.

Great! Now we need to port this to D6.

@webchick:
Do you think the UI change is acceptable (the API one won't be present) or will I just reroll catch's original patch?

Hm. I would maybe offer both options. Gábor will need to make the call. I think that not having the visual distinction between disabled and enabled is going to cause enough UX confusion to warrant breaking the UI, but it's his call.

I missed this one, maybe because the API change tag was removed at the end.

Do we need to announce this? If so, please let me know what to tell people.

Thanks,
-Randy

@rfay:

Do we need to announce this? If so, please let me know what to tell people.

I ain't sure about this: the values returned by http://api.drupal.org/api/function/field_content_languages/7 actually changed, but its semantic remained the same, so I think most code using it should not need to be changed.

Anyway the change is that now field_content_languages returns also disabled languages.

Related issue: #1060304: Misleading help text for the translation support settings.

Here is a backport of the committed patch. The UI change has not been ported (far too late for that I guess), so translators just get all the available languages in the language selector as a unique group.

The patch ships also the additional 'language_native_enabled' to allow to hide/replace the native English language if needed. This part needs a feedback from Gabor and might not get into D6 core.

Hm, can I get a rundown of what each part does. I don't think I understand the goal of most of the ones.

The translation.module hunks enable users with the 'translate content' permission to create nodes in disabled languages (translation links only show translations for enabled languages).

The bootstrap.inc/node.admin.inc hunk add a system variable that allows to remove the native english language from the list of installed languages without actually uninstalling it. This is needed at this point because native english can be disabled and people might want to prevent translators from creating english content. They might also want to replace it with an english local variant.

This is need wt this point because native english can be disabled and people might want to prevent people from creating english content.

Yes, it can be disabled, and that prevents people from submitting English content. Not sure what is the issue here.

With this patch people actually can create content in disabled languages.

Yes, I got that from the title already. That is what these 4 lines do in the patch, although I don't get why did you not modify the locale code that actually generates this field. Creating content in disabled languages (vs. translating to disabled languages) is a feature that could be desired just as much, right?

+    // Allow translators to enter content in disabled languages.
+    if (user_access('translate content')) {
+      $form['language']['#options'] = array('' => t('Language neutral')) + locale_language_list('name', TRUE);
+    }

Let me ask once again: how is the rest of the hunks related and what do they do?

Talked with Gabor and Jose Reyero in IRC and this subject is too controversial to backport the D7 patch to D6. So, as for many other i18n-related issues, the D6 solution here is installing i18n and use the content type options to select the desired mode.