Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By joel_guesclin on
I can't propose to develop, but I can offer what might be a realistic wishlist for a great system. So here is my "fantasy Drupal 4.5.0":
- locale and i18n modules both move into core in such a way that I can maintain a truly multilingual website:
- ability to maintain content in multiple languages (and different content for each language where necessary), but with a common structure for administration, users, etc;
- ability to share and import translations easily;
- ability for anonymous or registered users to switch languages without having to change their user settings
- groups module moves into core so that I can restrict admin access to certain parts of the site (eg to certain books, to certain static pages, to administering a particular language) to particular users;
- books module allows the definition of a maximum "level" for a book so that the book hierarchy drop-down list is no longer cluttered up with all the leaf articles.
I would be interested to know how this fits with other people's priorities and what are the chances of it being implemented in whole or in part?
JG
Comments
100% agree with full multilin
100% agree with full multilingual support.
That would be a killer feature.
Also, a FAQ module can be useful to many.
Thanx
book module
i solved the book module need by adding a link below book nodes called 'create book page here'. users now create book pages by clicking that link instead of through the create content menu. clicking that link pre-fills the 'parent' field too. this required a 1 line change to node.module
Good idea but...
Good idea, and is it possible to have the code to stick into my own module?
Also, it doesn't help the problem I have of importing articles from the old HTML pages. I plan to use the import_node module, but this leaves everything at book root level and i will have to administer all the pages to get them to the right level - so it would still be a useful change in the code even if less urgent perhaps.
About multilingual support (i18n module)
There will be some new features in next releases, some of them already working in the cvs version:
- Language dependent tables. Any table can be made language dependent, I mean you can keep separate tables for each language
- Full node and taxonomy synchronization between languages. This is about keeping ids in sync between languages, so nodes, vocabularies and terms with the same ids will be different language versions of the same content. You can select which node types are to be synchronized.
- Language dependent variables. As some of the content -site name, site mission, body of welcome e-mail... - is language dependent and I don't think the locale system is the ideal solution to have this stuff translated, there will be a configurable list of variables which will be kept separated for each language * This requires minimal patching
ABOUT MOVING INTO THE CORE
I prefer the idea of having separate modules, which implement a predefined api -locale api, i18n api....- , and can be replaced by a better or simpler module. For i18n module to be working properly and to avoid ugly hacks, I would need only a few patches of the type if(function_exists('i18n_url_rewrite'))......
SOME USABILITY ISSUES
To fully use this module's capabilities, some low level configuration is required, like defining in the config file which tables or which variables are to be made language dependent, and also creating and renaming some tables. The module's config page is also starting to get too complex.
I'm thinking of:
- removing some config options which will be available anyway in the config file
- having some predefined sets of options and scripts like 'multilingual stories','multilingual taxonomy'....
* As I am in the process of defining for which tables and variables it makes sense to be language dependent and for which ones doesn't. For the moment I'm keeping all the config options available but this may change as I've realized it presents serious usability issues for average users.
Any suggestions?
https://reyero.net
More on multilingual support
This all sounds very promising - I hope to try out the latest version asap when I get back from holiday.
Couple of comments to add some ideas:
- content translation: excellent idea about "select which node types are to be synchronized"; would it be possible to go further and for example select which books should be synchronised?
- security: would it be possible to restrict users to administering content in a particular language?
Better performance: reimplementing hooks
I am re-posting this here; I had posted it in 'Drupal 4.5.0 battle plans' but as Dries pointed out, it was the wrong place
As Drupal is getting bigger and specially when you are using a lot of modules I am concerned about overall performance. I think too much iddle code is included every time a page is generated.
The bootstrap system, which takes care of the init hook, is a big step ahead, and I think is the way to go for the rest of the modules' hooks.
We need a hook system, that stores and manages all the hooks in the database and takes care of which files to include.
The hooks should be linked with a specific file, better than with a module, thus allowing big modules to be split in several files.
Also, some kind of 'install/uninstall/enable/disable' hook should be created allowing modules to take care of hook registration and maybe some more istallation tasks. Notice that a module needs to register the hooks itself because specific hooks can be implemented in a separate file, other than main .module file.
https://reyero.net