|
Good call. This version of the patch whould correct that, though I don't have another, single language CiviCRM setup handy to test
I modified the patch a bit and applied in r20301 for 2.2.1 - thanks a lot for the contribution!
Aaaargh, not fixed. Apologies.
I'm sorry, but I couldn't fix it for 2.2.3 (and we want to release it tomorrow-ish). I'll fix this for 2.2.4 (provided I find the elusive issue that manifests itself on civicrm.org but not in my sandbox...).
Moving to 2.3, as we're too close to 2.2.4 and last time the fix, while seemingly simple, broke a few things. I'll fix this as a part of my GSoC work and backport to a future 2.2 release if deemed safe.
Finally fixed in r23411 - after debugging it thoroughly, the problem was that Drupal not only sets the global $language object's prefix property, but also the language_negotiation config variable, and it must be set to either LANGUAGE_NEGOTIATION_PATH_DEFAULT or LANGUAGE_NEGOTIATION_PATH for Drupal to properly route the language-prefixed URLs.
If we switch Drupal prefix we need to rebuild menus.
This patch applies to 3.0-beta4 and ensures that path prefixing is only done if local module is enabled. This is needed for the case where locale was once enabled, and path prefixes were used but local has since been disabled (but not uninstalled). Without this patch, the presence of variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE) alone was enough to triger the path prefixing.
Thanks, Tom - your patches are most appreciated! Lobo applied your patch to 3.0 in r23744, we keep this issue open for 3.1 as we also need to rebuild menus on Drupal language switch (Kiran's last comment).
Actually, the gist of the issue (retaining language prefix) is fixed and working. We have a separate issue for inheriting language from Drupal/Joomla!:
assigning for 3.1 verification
Verified for 3.1 in r25645.
|
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Trivial
Drupal path prefix for multilingual sites should be retained throughout CiviCRM.
this patch wont really work on default install. the language variable is always set, even on default installs which dont use prefixing
stdClass Object
(
[language] => en
[name] => English
[native] => English
[direction] => 0
[enabled] => 1
[plurals] => 0
[formula] =>
[domain] =>
[prefix] =>
[weight] => 0
[javascript] =>
)
lobo