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).
Comment | File | Size | Author |
---|---|---|---|
#19 | tf-632172-19.patch | 725 bytes | plach |
#10 | tf-632172-10.patch | 720 bytes | plach |
#7 | tf-632172-7.patch | 1.44 KB | plach |
#6 | tf-632172-6.patch | 5.37 KB | plach |
#4 | tf-632172-4.patch | 4.62 KB | plach |
Comments
Comment #1
plachThe current patch generalize Locale's behavior and enforce it for any module.
Comment #2
plachComment #4
plachthis one should work
Comment #6
plachI removed the static caching from
drupal_multilingual()
which seemed really useless and prevented tests from pass.Comment #7
plachThe 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.
Comment #8
yched CreditAttribution: yched commentedSubscribe
Comment #9
plachThe
drupal_multilingual()
static caching issue is being fixed in #710860: Static caching in drupal_multilingual() breaks tests.Comment #10
plachPatch rerolled without the above hunk.
Comment #12
plachThis depends on #710860: Static caching in drupal_multilingual() breaks tests to pass tests.
Comment #13
SAURABH01 CreditAttribution: SAURABH01 commented#1: tf-632172-1.patch queued for re-testing.
Comment #14
plach@SAURABH01: as I wrote in #12 this won't pass the tests until #710860: Static caching in drupal_multilingual() breaks tests is committed.
Comment #15
plach#10: tf-632172-10.patch queued for re-testing.
Comment #17
plach#10: tf-632172-10.patch queued for re-testing.
Cannot reproduce any error on my box.
Comment #18
catchThis 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).
Comment #19
plachJust 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.
Comment #20
catchMakes more sense, still fixes tests failures on the other issue, back to rtbc.
Comment #21
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #22
boaz_r CreditAttribution: boaz_r commentedFor 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.
Comment #23
plach@Boaz: please open a new issue, this is definitely the wrong place.