"Enable Multiple Languages" causes "Critical error"

Thanks @PinkSeal for reporting the issue. As you probably know CiviCRM is open source software and maintained by a community of volunteers. Do you have any development skill and do you want to help to fix this issue? If not no problem.

Oh, sorry just answered that on the other issue: Yes, I do have some PHP programming skills. I'm planning to contribute and fix these issues, once I got more comfortable with CiviCRM.

That is great. Let me know if you need any help (best way to attract my attention is send a message on mattermost).

added in-triage label

added git:civicrm-core regression sig:bug triaged labels

removed in-triage label

I have given this the regression bug as this used to work. If anyone thinks it is not a regression feel free to remove the label.

same thing after installing latest from 6 branch standalone i don't have php skills... but i can provide this

MariaDB [XXX]> show columns from civicrm_option_value_en_US;

+-----------------+------------------+------+-----+---------+-------+
| Field           | Type             | Null | Key | Default | Extra |
+-----------------+------------------+------+-----+---------+-------+
| id              | int(10) unsigned | NO   |     | 0       |       |
| option_group_id | int(10) unsigned | NO   |     | NULL    |       |
| value           | varchar(512)     | NO   |     | NULL    |       |
| name            | varchar(255)     | YES  |     | NULL    |       |
| grouping        | varchar(255)     | YES  |     | NULL    |       |
| filter          | int(10) unsigned | YES  |     | 0       |       |
| is_default      | tinyint(1)       | YES  |     | 0       |       |
| weight          | int(10) unsigned | NO   |     | NULL    |       |
| is_optgroup     | tinyint(1)       | YES  |     | 0       |       |
| is_reserved     | tinyint(1)       | YES  |     | 0       |       |
| is_active       | tinyint(1)       | YES  |     | 1       |       |
| component_id    | int(10) unsigned | YES  |     | NULL    |       |
| domain_id       | int(10) unsigned | YES  |     | NULL    |       |
| visibility_id   | int(10) unsigned | YES  |     | NULL    |       |
| icon            | varchar(255)     | YES  |     | NULL    |       |
| color           | varchar(255)     | YES  |     | NULL    |       |
| label           | varchar(512)     | NO   |     |         |       |
| description     | text             | YES  |     | NULL    |       |
+-----------------+------------------+------+-----+---------+-------+
18 rows in set (0.001 sec)

MariaDB [XXX]> show columns from civicrm_option_value;

+-------------------+------------------+------+-----+---------+----------------+
| Field             | Type             | Null | Key | Default | Extra          |
+-------------------+------------------+------+-----+---------+----------------+
| id                | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| option_group_id   | int(10) unsigned | NO   | MUL | NULL    |                |
| value             | varchar(512)     | NO   | MUL | NULL    |                |
| name              | varchar(255)     | YES  | MUL | NULL    |                |
| grouping          | varchar(255)     | YES  |     | NULL    |                |
| filter            | int(10) unsigned | YES  |     | 0       |                |
| is_default        | tinyint(1)       | YES  |     | 0       |                |
| weight            | int(10) unsigned | NO   |     | NULL    |                |
| is_optgroup       | tinyint(1)       | YES  |     | 0       |                |
| is_reserved       | tinyint(1)       | YES  |     | 0       |                |
| is_active         | tinyint(1)       | YES  |     | 1       |                |
| component_id      | int(10) unsigned | YES  | MUL | NULL    |                |
| domain_id         | int(10) unsigned | YES  | MUL | NULL    |                |
| visibility_id     | int(10) unsigned | YES  |     | NULL    |                |
| icon              | varchar(255)     | YES  |     | NULL    |                |
| color             | varchar(255)     | YES  |     | NULL    |                |
| label_en_US       | varchar(512)     | NO   |     |         |                |
| description_en_US | text             | YES  |     | NULL    |                |
+-------------------+------------------+------+-----+---------+----------------+

this is how it looks after pressing Enable Multiple Languages i hope this can help

marked this issue as related to #5031 (closed)

This seems related to #1132 (closed) - maybe it's the opposite problem?

after hours with claude 3.7 agent:

The Multilingual Architecture Mystery Solved!

Now I have the complete picture of what's happening:

How CiviCRM's Multilingual System Actually Works Database Schema Architecture: Base Table: civicrm_option_value has language-specific columns like label_en_US and description_en_US Language View: civicrm_option_value_en_US is a VIEW that maps these language-specific columns to generic column names (label_en_US AS label) Query Handling Process: In a properly functioning CiviCRM installation, queries using generic column names like label should be: Either rewritten to use the language-specific columns Or automatically directed to the appropriate language view The $dbLocale Global Variable: When set correctly (_en_US), it triggers CiviCRM's rewriteQuery() function This function transforms table references to include the language suffix (e.g., civicrm_option_value becomes civicrm_option_value_en_US)

Why WordPress Works But Standalone Doesn't Both installations have identical schema (as you confirmed), but:

WordPress/Drupal Setup: The CMS bootstrap properly initializes the $dbLocale global variable CRM_Core_I18n_Schema::rewriteQuery() is correctly integrated into the query execution path Queries are properly transformed to use the language views

Standalone Setup: The bootstrap sequence is different The $dbLocale variable is set, but query rewriting isn't fully integrated Some queries bypass the transformation process, resulting in references to non-existent columns

The Optimal Solution Rather than adding columns to the database (which would break the multilingual design), the correct approach is what your fix is doing: Intercept Problematic Queries: Use a query filter to catch queries before execution Transform References: Modify references to generic columns to use existing counterparts Consistency: This maintains the CiviCRM multilingual architecture without schema changes This approach is minimal, focused on the specific problem, and maintains consistency with how multilingual support is supposed to work in CiviCRM.

@PinkSeal what do you say?

may be maintainers can help with direction here?

thanks

@yosefy could you say more about "query rewriting isn't fully integrated"? What query specifically is not behaving properly?

@colemanw after digging a bit more (this time without AI ) looks like $dbLocale is not being set in vendor/civicrm/civicrm-core/Civi/Standalone/WebEntrypoint.php printed it in error log looks empty so it tries to query in strange ways so i am not sure again how to continue.

i don't know how to continue... AI is not very helpful proposing all types of strange solutions is it expected to work at all? should i stop trying to use standalone version? please help with some advice here. thanks

from claude 3.7:

Based on my research, I can now explain the key difference in how WordPress and standalone versions handle multilanguage support, particularly regarding database views.

How WordPress Handles Multilanguage Database Views

In the WordPress version of CiviCRM, the multilanguage support works correctly because: Global $dbLocale Variable: When multilanguage is enabled, the system sets a global $dbLocale variable (in CRM_Core_I18n::setLocale()) which contains the locale suffix (e.g., "en_US"). Query Rewriting: The CRM_Core_DAO::query() method checks if $dbLocale is set and if so, it calls CRM_Core_I18n_Schema::rewriteQuery() to modify SQL queries to use the localized table views.

Table Name Transformation: The CRM_Core_DAO::getLocaleTableName() method appends the $dbLocale suffix to table names for multilingual tables, ensuring queries use the correct language-specific views.

WordPress-Specific Locale Detection: The WordPress system class (CRM_Utils_System_WordPress) has a robust getUFLocale() method that properly detects the current locale from WordPress, considering both admin and frontend contexts.

Bootstrap Process: In WordPress, the CMS bootstraps first, then CiviCRM, allowing the locale information to be properly passed from WordPress to CiviCRM.

What's Missing in the Standalone Version

The standalone version lacks some critical components: No UF Locale Method: The standalone system class (CRM_Utils_System_Standalone) doesn't implement a getUFLocale() method, which is crucial for determining the current locale. Incomplete postContainerBoot(): The standalone version's postContainerBoot() method only sets the timezone but doesn't properly initialize the locale or $dbLocale variable. No Locale Initialization: There's no code in the standalone version that ensures the $dbLocale global variable is properly set during system initialization. Missing Database Connection Handling: The standalone version doesn't have code to ensure database queries use the language-specific views created during multilanguage setup.

The Specific Issue

When multilanguage support is enabled in CiviCRM:

The system creates language-specific database views (e.g., civicrm_option_value_en_US) that map language-specific columns to their base names.

In WordPress, when a query is executed, the $dbLocale variable is set, and CRM_Core_DAO::query() rewrites the query to use these views.

In the standalone version, this rewriting mechanism is present in the core code, but the $dbLocale variable isn't properly initialized during bootstrap, so the query rewriting doesn't happen. As a result, when EntityMetadataBase.php tries to access the label column in civicrm_option_value, it's looking at the base table (which now has columns like label_en_US) instead of the language-specific view that would map label_en_US back to label.

The Fix To fix this issue in the standalone version, you would need to: Implement a proper getUFLocale() method in CRM_Utils_System_Standalone that returns the current locale. Enhance the postContainerBoot() method to properly initialize the $dbLocale global variable based on the current locale. Ensure that database connections in the standalone version are properly set up to use the language-specific views. This is why the issue only occurs in the standalone version - the WordPress and Drupal versions have the necessary code to properly initialize and use the $dbLocale variable, ensuring queries are rewritten to use the language-specific views.

i have put wordpress, drupal and standalone versions in one dir and asked cursor ide agent (using claude 3.7) to investigate the problem with standalone version and why it doesn't happens in 2 others... i hope may be it may help somehow

Great work. Sorry, I wont have time to dig into this right now. Hope you can find some solution.

So comes out the locale part is not handled at all in standalone. So it is not about fixing a bug but about implementing a feature

...

On Thu, Mar 6, 2025, 2:39 PM PinkSeal (@PinkSeal) info@civicrm.org wrote:

PinkSeal https://lab.civicrm.org/PinkSeal commented on a discussion #5714 (comment 178449):

Great work. Sorry, I wont have time to dig into this right now. Hope you can find some solution.

— Reply to this email directly or view it on GitLab #5714 (comment 178449). You're receiving this email because of your account on lab.civicrm.org. Unsubscribe https://lab.civicrm.org/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://lab.civicrm.org/-/profile/notifications · Help https://lab.civicrm.org/help

Function that handles it in WordPress and Drupal is empty in standalone and even if we create it , there are parts of code that don't use it somehow. I guess there are workarounds in CMS implementation. I am still trying

...

On Thu, Mar 6, 2025, 2:44 PM Yosef Yudilevich yosef.yudilevich@gmail.com wrote:

So comes out the locale part is not handled at all in standalone. So it is not about fixing a bug but about implementing a feature

On Thu, Mar 6, 2025, 2:39 PM PinkSeal (@PinkSeal) info@civicrm.org wrote:

PinkSeal https://lab.civicrm.org/PinkSeal commented on a discussion #5714 (comment 178449):

Great work. Sorry, I wont have time to dig into this right now. Hope you can find some solution.

— Reply to this email directly or view it on GitLab #5714 (comment 178449). You're receiving this email because of your account on lab.civicrm.org. Unsubscribe https://lab.civicrm.org/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://lab.civicrm.org/-/profile/notifications · Help https://lab.civicrm.org/help

added comp:Standalone sig:standalone standalone beta-blocking labels

added prioritised label

I've removed the regression as this appears like a 'never worked in standalone issue' not a regression

removed regression label

A pull request related to this issue has been opened with the title: #5714 Ensure that Standalone sites do not crash when in multi…

mentioned in issue #5031 (closed)

I think this may fix the immediate crash https://github.com/civicrm/civicrm-core/pull/32444

There is then some work to enable locale negotiation - i.e. how is the correct locale for a user / anon user determined (in all the other UFs, this comes from the UF).

I'm not sure about the stuff from Claude about not filtering all the queries... I don't think Standalone has any bearing on how any queries are filtered or not-filtered. I suspect that may be hallucination...

A pull request related to this issue has been opened with the title: #5714 standalone - move timezone setting to hook_civicrm_config

mentioned in commit 1e8d37a5

"Enable Multiple Languages" causes "Critical error"

Overview

Reproduction steps

Current behaviour

Expected behaviour

Environment information

Comments

Child items ...

Activity

The Multilingual Architecture Mystery Solved!