#282191: TF #1: Allow different interface language for the same path includes changes to the global language variables to accompany a removal of content language negotiation UI from core.

To double check that nothing was broken, it's necessary to review all places using the global $language variable to ensure they have the correct language type and file patches for any issues found.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

This is needed because currently content language inherits the value of interface language, so in core using the former or the latter makes no difference. But contrib modules can alter this, so we have to ensure all places use the right language type.

plach’s picture

Priority: Critical » Normal
Language type Context Interested code Status Notes
UI Menu menu_tree_all_data, menu_tree_page_data, _menu_tree_cid OK Used to create cache Ids. Menus are UI components so this should be fine.
UI Language direction template_preprocess_html, template_preprocess_page, template_preprocess_maintenance_page, openid_redirect, template_preprocess_book_export_html ? Used to get language direction. UI seems to be a sensible choice, but see #780508: Set language by content language for LTR/RTL display for an opposite scenario.
UI UI translation t, format_date, _locale_parse_js_file, _locale_parse_js_file, locale_language_selector_form, locale, locale_get_plural, locale_js_alter, locale_css_alter, locale_library_alter, LocaleUninstallFunctionalTest::testUninstallProcess, CascadingStylesheetsTestCase::testAlter, FormatDateUnitTest::testFormatDate OK Used explictly as UI language. No doubts here IMO.
UI RSS format_rss_channel, node_feed NO Used as default channel language when no language is explictly specified. As this indicates the language of the RSS items, IMO it should be changed to content language.
UI Documentation url NO The phpdocs say that if $options['language'] is empty the value of $language will be used, but drupal_lookup_path() uses $language_content.
UI Documentation hook_language_switch_links_alter NO The example code is simply wrong: it uses a language object as a language code.
UI Documentation hook_block_list_alter, hook_watchdog OK
Content URL drupal_lookup_path OK In Drupal 6 path aliases are tied to node's language which is the closest thing to $language_content available in D6.
URL URL l, locale_language_url_rewrite_url, theme_links OK Used when no language is explictly specified. Intended use. No problems here.
UI Cache drupal_render_cid_parts ? Used to compute cache ids. It might be not enough as we might have the same node displaying different content (per language) with the same UI language.
UI Cache entity_get_info, _field_info_collate_types, image_effect_definitions OK Used to cache translatable strings per language.
UI Locale locale_language_from_interface OK Intended use. No problems here.
UI Color _color_html_alter, _color_page_alter ? Do not seem to use language at all.
UI Token test Token test: CommentTokenReplaceTestCase::testCommentTokenReplacement, FileTokenReplaceTestCase::testFileTokenReplacement, NodeTokenReplaceTestCase::testNodeTokenReplacement, PollTokenReplaceTestCase::testPollTokenReplacement, StatisticsTokenReplaceTestCase::testStatisticsTokenReplacement, TokenReplaceTestCase, UserTokenReplaceTestCase::testUserTokenReplacement OK Used as URL language and to format dates. Should work.
UI Test TaxonomyTokenReplaceTestCase::testTaxonomyTokenReplacement, DrupalWebTestCase::setUp, DrupalWebTestCase::tearDown OK Used when no language is explictly specified. Intended use. No problems here.
Content Field field_valid_language OK Intended use. No problems here.
UI Comment locale_form_comment_form_alter NO Used to assign a language to comments: the (optimistic) assumption is that one posts a comment in the same language of the main content. With node translations one can post a comment having an actual language different from the node's one, but comments are tied to the node's language anyway. Hence IMO this should be content language.
UI Mail MailTestCase::testPluggableFramework, user_pass_submit, contact_site_form_submit, contact_personal_form_submit OK Mail messages are sent using the UI language.
plach’s picture

Status: Active » Needs review

Comments are welcome.

plach’s picture

Priority: Normal » Critical

Upgrading to critical as having parts of the drupal core using the wrong language type is a serious issue. OTOH this should not be a hard one to fix as it only involves switching some global variables around, but IMHO it's a must-fix.

Jolidog’s picture

I don't think this is critical, but it shouldn't be forgotten.
Perhaps adding the priority major tag is a good compromise?

plach’s picture

Perhaps adding the priority major tag is a good compromise?

I'd like to have a committer feedback about this.

catch’s picture

Status: Needs review » Active

The thing which makes this more critical than normal is the comment language - since that could lead to inconsistent data, but I think it's going to be sufficiently rare that 'major' would be fine if we had that priority, but I imagine this will get patched and fixed before that priority is on Drupal.org anyway.

Looking at the table those changes all look fine, but there is no patch here, so back to active.

plach’s picture

Priority: Normal » Critical

A couple of tricky ones are:

  • drupal_render_cid_parts(), I'd like the hear moshe about it
  • language direction, which IMO needs some thinking about
catch’s picture

For drupal_render_cid_parts() I would use content language - if you need to do something tricky with user language you could specify that yourself via 'cid' instead of using the helper iirc.

language direction, no idea :(

moshe weitzman’s picture

drupal_render_cid_parts basically tries to recreate http://api.drupal.org/api/function/_block_get_cache_id/6. so, i would do whatever you would do for that code. hope that helps.

haaiee’s picture

Removed my own comment as it was not relevant.

plach’s picture

Status: Active » Needs review
FileSize
5.01 KB

The patch performs the corrections suggested in #2.

The drupal_render_cid_parts() issue has been addressed by adding as cid parts all the configurable language types: this means that in core the behavior is exactly the same as before, but if a contrib module enables additional configurable language types (I'm thinking mainly about content language) they will be used as cid parts too. This choice should let us handle pages displaying content available in multiple languages which could have different cache entries for every combination of UI/content languages.

I left unchanged the language direction issue because I think UI language is the correct choice in the scopes it is used (i.e. page level). In #780508: Set language by content language for LTR/RTL display we can try to introduce a content-level scope to achieve separate language directions for page-level and content-level scopes (i.e. what's sketched in http://drupal.org/files/issues/rtl.png).

plach’s picture

FileSize
5.1 KB

I forgot a comment.

plach’s picture

FileSize
5.53 KB

Again wrong patch, sorry :(

sun’s picture

Agreed on deferring language direction to #780508: Set language by content language for LTR/RTL display. The page/document must use UI language, inner elements may define language direction based on content language; specifying language itself additionally helps crawling machines/spiders.

+++ includes/common.inc	29 Jun 2010 22:16:48 -0000
@@ -5321,9 +5321,12 @@ function drupal_render_cid_parts($granul
+  // If Locale is enabled but we have only one language we do not need it as cid
+  // part.
+  if (drupal_multilingual()) {
+    foreach (language_types_configurable() as $language_type) {
+      $cid_parts[] = $GLOBALS[$language_type]->language;
+    }
   }

Very nice - dynamically using zero to both is exactly what I wanted to suggest. This should support any, from simple to advanced, language environments.

If I did not overlook something, then this patch contains all required changes already? Or are we still missing something? If not, RTBC?

44 critical left. Go review some!

plach’s picture

@sun:

Thanks for reviewing! The patch in #14 should address all the pending issues except language direction.
Feel free to RTBC if you don't have any remark.

sun’s picture

Status: Needs review » Reviewed & tested by the community
plach’s picture

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

MustangGB’s picture

Priority: Critical » Major
MustangGB’s picture

Tag update

Status: Fixed » Closed (fixed)

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