If Locale is disabled there is no way in core to enable multilingual support for fields, but if one wishes to translate the user interface on a non-english unilingual site has to enable Locale.

Currently Locale registers itself as a translation handler (i.e. enables multilingual support for fields) only if the site is multilingual, which is the desired behavior. However this logic should be adopted by all the modules which register themelves as translation handlers (e.g. #539110: TF #4: Translatable fields UI).

CommentFileSizeAuthor
#19 tf-632172-19.patch725 bytesplach
#10 tf-632172-10.patch720 bytesplach
#7 tf-632172-7.patch1.44 KBplach
#6 tf-632172-6.patch5.37 KBplach
#4 tf-632172-4.patch4.62 KBplach
#1 tf-632172-1.patch4.61 KBplach
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Active » Needs review
FileSize
tf-632172-1.patch4.61 KB

The current patch generalize Locale's behavior and enforce it for any module.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Issue tags: +translatable fields

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Needs work » Needs review
FileSize
tf-632172-4.patch4.62 KB

this one should work

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Needs work » Needs review
FileSize
tf-632172-6.patch5.37 KB

I removed the static caching from drupal_multilingual() which seemed really useless and prevented tests from pass.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Title: Field translations should be always disabled for unilingual sites. » Node language and field languages may differ
Category: task » bug
FileSize
tf-632172-7.patch1.44 KB

The main purpose of this patch was to intoduce a coherent behavior for unilingual sites: at the moment an english site does not need any field fallback logic to be run, while a non-english unilingual site, by enabling Locale, would trigger field fallback logic's activation. For this reason Locale currently registers itself as a field translation handler only if the site is multilingual. This behavior introduces a possible misalignment between node language and the attached field languages.

With #657972: Make field fallback logic actually reusable fallback logic should have a lighter performance impact so we don't need this anymore; instead we need Locale to ensure that node language and field languages are always the same.

yched’s picture

yched CreditAttribution: yched commented

Subscribe

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented

The drupal_multilingual() static caching issue is being fixed in #710860: Static caching in drupal_multilingual() breaks tests.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Issue tags: +Quick fix
FileSize
tf-632172-10.patch720 bytes

Patch rerolled without the above hunk.

Status: Needs review » Needs work

The last submitted patch, tf-632172-10.patch, failed testing.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Needs work » Needs review

This depends on #710860: Static caching in drupal_multilingual() breaks tests to pass tests.

SAURABH01’s picture

SAURABH01 CreditAttribution: SAURABH01 commented

#1: tf-632172-1.patch queued for re-testing.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented

@SAURABH01: as I wrote in #12 this won't pass the tests until #710860: Static caching in drupal_multilingual() breaks tests is committed.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Issue tags: -Quick fix, -translatable fields, -API clean-up

#10: tf-632172-10.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, tf-632172-10.patch, failed testing.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Needs work » Needs review
Issue tags: +Quick fix, +translatable fields, +API clean-up

#10: tf-632172-10.patch queued for re-testing.

Cannot reproduce any error on my box.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

This fixes the last remaining test failure on #553306: Make nodes have no body field by default. Remove deprecated APIs for body field. Bumping to critical since it's a blocker (but not merging patches since I don't want to hold this one line fix up).

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Reviewed & tested by the community » Needs review
FileSize
tf-632172-19.patch725 bytes

Just noticed that Locale enables multilingual fields for any entity, but handles just node's fields. This behavior is an heritage of when entity translation was planned in core. The attached patch enables only node fields, thus avoiding the (unsupported) multilingual workflow for taxonomy, user and comment fields. Probably a small performance gain.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Status: Needs review » Reviewed & tested by the community

Makes more sense, still fixes tests failures on the other issue, back to rtbc.

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

boaz_r’s picture

boaz_r CreditAttribution: boaz_r commented

For those running i18n version (at least v 6.x-1.1 that I use), you might need another patch:

I'm running an older Drupal system - 6.8 and several modules, among which i18n. For me, I had to manually examine the involved code, and do a thorough scan (grep) on the entire code base to find what I was looking for:

it appears that in i18n.module (v6.x-1.1), line 561, there's a line: $form['language']['#options'] = i18n_node_language_list($form['#node'], TRUE);
When it runs, it overwrites the previously modified #options, dropping the not-enabled languages and leaving the form element with partial language list and doesn't touch the default_value that has the value of the not-currently-enabled language that you've selected to translated to. I'm pretty sure that during theming phase for this form element, since the default value is not in the options list, it dropped in favor of the "language neutral" (maybe the first option on the options list), and we're back with the original problem (inability to translate nodes to a disabled language).

If you want to fix this, you can try what I did, assuming that locale module is always enabled (such as in our case). Change the line stated above to the following: $form['language']['#options'] = locale_language_list('name', TRUE);

Boaz.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented

@Boaz: please open a new issue, this is definitely the wrong place.

Status: Fixed » Closed (fixed)
Issue tags: -Quick fix, -translatable fields, -API clean-up

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

Issue tags: +Quick fix, +translatable fields, +API clean-up

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.