Taxonomy's not merged?

There is more than one taxonomy module since we can't alter taxonomy.module in core without patching. So Localizer works with Taxonomy (Localizer) while your site will use regular Taxonomy module if you do not enable Localizer.

And since category.module also replaces taxonomy.module with a customized version, the third module, Taxonomy (Category/Localizer) is needed.

Having multiple version of the same module in the list is causing too much confusion.

I prefer to have a clean and easy system where the user has the complete control on it.

If localizer crashed and you removed it, you are not more able to reset the modules
entry but in phpmyadmin.

It is sufficient to put the modified versions of the modules under sites/all/modules directory.
If something goes wrong or you want to disable localizer you can simply remove the files
from there.

Just placing the modified modules in sites/all/modules was also the first approach. But there are two reasons why this is not a working solution:

1. It depends on the filesystem if the modules in /sites/all/modules are really indexed after core modules in /modules. If - for whatever reason - core modules are indexed after contrib modules, the wrong modules are indexed. F.e. I've seen users installing contrib modules in /modules/_contrib in the past, alternative Drupal installation guides using symbolic links and multi-site setups using completely different directory structures.
2. Since there are also other contrib modules that need (and install) wrappers for core modules, the modified versions of Localizer are breaking the site. F.e. the popular Category module needs a wrapper module for taxonomy module.

I think that changing entries in system table is too much dangerous.

Scenario : you activate localizer, change the system table, your
website crash. You are not more able to restore the original entries
in system table.

Having multiple entries in module section can create a lot of confusion.

Then the only working solution is to step back to patching core files. We've thought hours about this issue. As long as there is no independent (3rd party) compatibility module which handles such replacements, each contrib module performing such tasks will break a site in certain scenarios.

I have some proposals :

1. checks in Drupal core code the order of modules loading to be 100% sure the sites/all/modules
solution cannot work

2. for category taxonomy wrapper we could talk with category module author and see if we can cooperate
to merge our changes in some manner

3. patches for cache are already solved with the use of cache_inc settings variable.

We have to find a solution for menu, block and taxonomy.

Patch for menu is really really simple and it is more a bug fixing than a patch for
making localizer work.

Block : we could also think to write a specialized version of this module and call it,
for example : localizer_block.

If we are not able to find a solid solution we'll continue with patches, providing
to the users the already patched versions keeping them aligned with Drupal versions.

What do you think ?

The 'localized' category wrapper module is only needed if someone wants to have legacy taxonomy support. I'm currently not sure, what is actually affected from category's taxonomy legacy implementation. The downside is that maintainers of Category module seem to be not very active, because a simple compatibility patch is in the queue for quite some time now.

Core modules can not be replaced with modules that have different names. If a replacement module has a different name, module_invoke() does not work anymore. Furthermore, there are contrib modules, theme engines and themes that rely on the existence of certain functions in those modules. Actually, this is the reason why this approach in 5.x-2.x broke some sites.

So, as long as the already mentioned, independent Compatibility module does not exist, patching core files is the only solution that is left. Additionally, we shouldn't provide already patched core files, because

• some users will fail to replace core files and create duplicates instead
• patches will apply longer than direct module replacements

@hass: Sure, that sounds simple. However, please compare taxonomy.module in core with the taxonomy wrapper module of Category module in front of making assumptions. Merging both modules into one, including the necessary changes for Localizer is simply not maintainable, since we would have to react on any changes in taxonomy or category module and merge them accordingly into that module. Neither Roberto nor me would have the time to do and ensure that.

@sun
> It depends on the filesystem if the modules in /sites/all/modules are really indexed after core modules in /modules

Yes, it seems that sites/all is indexed after the main directory.

in includes/common.inc, function drupal_system_listing starting from row 2074.

  $searchdir = array($directory);                                                                              
  $files = array();                                                                                            
                                                                                                               
  // Always search sites/all/* as well as the global directories                                               
  $searchdir[] = 'sites/all/'. $directory;                                                                     
                                                                                                               
  // The 'profiles' directory contains pristine collections of modules and                                     
  // themes as organized by a distribution.  It is pristine in the same way                                    
  // that /modules is pristine for core; users should avoid changing anything                                  
  // there in favor of sites/all or sites/<domain> directories.                                                
  if (file_exists("profiles/$profile/$directory")) {                                                           
    $searchdir[] = "profiles/$profile/$directory";                                                             
  }                                                                                                            
                                                                                                               
  if (file_exists("$config/$directory")) {                                                                     
    $searchdir[] = "$config/$directory";                                                                       
  }                                                                                                            
                                                                                                               
  // Get current list of items                                                                                 
  foreach ($searchdir as $dir) {                                                                               
    $files = array_merge($files, file_scan_directory($dir, $mask, array('.', '..', 'CVS'), 0, TRUE, $key, $min_
  }

For the modules it is called in module.inc in this manner :

$files = drupal_system_listing('\.module$', 'modules', 'name', 0);

Because of this

$searchdir = array($directory); // is /modules
$searchdir[] = 'sites/all/'. $directory; // is /sites/all/modules
$searchdir[] = "profiles/$profile/$directory"; // is /profiles/default/modules or /profiles/xyz/modules
$searchdir[] = "$config/$directory"; // is /sites/example.com/modules or /sites/default/modules

you are not able to predict where a module is actually has to be placed to be found at last. Please bear in mind that Localizer should work with multi-site setups, too.
Don't get me wrong, I don't want to destruct all the options - it's just that we've really thought countless hours about this issue and played with any scenario we were able to come up with. Sadly, we did not even find all possible scenarios, as you can see in the issues for 5.x-2.x.

Ok, clear.
We cannot be sure at 100% neither with this solution.

So, we should maintain the patches option.

in the past I've been contacted by some users that had some difficulties
to apply the patches, so, I'm thinking to a "mixed" approach.

Maintain the patches in the main package.
Don't distribute the already patched files in the package, but maintain
a page of instructions in the manual or on a website referenced in the
installation instructions where the users can download the already patched files
and where we explain where they can put these files : replacing the originals
or under sites/all/modules if they prefer, making clear what can be the uncertainty.

Not tried yet, but perhaps it could work also creating a directory like
sites/all/modules/localizer/taxonomy.

i would like to have an easy solution also for users with not much experience
and that doesn't touch too much its system.
if something goes wrong of if the user is not happy with localizer, he
should be able to easily remove it.

It is for these reasons that I'm struggling so much on this issue.

Thanks to all for thought and feedback sharing !