I want create once module multi languages in drupal 7.x with i18n installed already.
Please help me step by step create that,
Thanks advance,
The home for all Drupal localization is now http://localize.drupal.org/. This is a good place to start reading about internationalization and translation.
As a developer, you should also look at the Drupal 7 i18n articles by kristen: http://www.kristen.org/drupal7-i18n-articles,
Also read this about .po files: http://drupal.org/node/1814954
The very short version of what you need to know as a developer :-) is that you should wrap the strings you want to translatable in the translate (t()) function, as shown here: http://hojtsy.hu/blog/2011-jan-25/drupal-7039s-new-multilingual-systems-part-3-localization-and-language-apis, and then translate the strings into the languages you're interested in by one of the means described below:
If you're translatable strings are part of an official Drupal project, translations contributed to http://localize.drupal.org/ will show up on your site next time translations are updated (there seems to be some delay of max 24 hours from a translation is accepted at http://localize.drupal.org/ to when updating has an effect). Updating can be configured to happen automatically with localization update: http://drupal.org/project/l10n_update
For custom modules, you can upload your own translations through the administrative interface of the same module (localization update).
Related
I have 4 XML files(rule set) for languages Java, CSS, XML and WEB (one XML per language)
I was able to import the rules(XML file) for Java language but I dont see other three languages on Sonarqube server. How can I create a new language tab and import their rules? Is there a plugin I can use?
Thanks!
To add support for more languages, you need to install dedicated plugins that you will find:
In the Update Center - read the documentation about it
Or in the list of other community plugins - in which case you have to install them manually by copying the plugin into <install_folder>/extensions/plugins folder
I am a student, I have a project for a client, www.wac-stl.org
they are running Drupal 6. I need to upgrade it to Drupal 7 to I can install CiviCRM.
What is the best way to do this? If you can take a look at the website, I think it is a very basic website, so do you imagine I would have any trouble upgrading?
Also, I only have FTP access to the website files, I do not have database access. Will this be a problem for me?
Thank you!
Option A: Upgrade
Definition: Replace D6 code with D7 code;
run upgrade scripts on D7
database Good only for really basic sites Most like your old site
Option B: Migrate
Definition: Install new D7 site from scratch with new database;
import content,
Views, users, etc.
Clean Codebase
Old content can be left out
Retweak IA
Tweak Data Model
Con: Content Cleanup takes time
There migration tools that can be used
Features - Allows you to export content-types, users and structures
(e.g. Taxonomy, Image-styles, etc.) into a module-like package An
excellent guide is available here:http://drupal.org/node/580026
Feeds - Feeds is a contributed module that allows one to import and
export content from a csv, xml, or rss format. Visit the feeds
project page for more information.
For "node-content" export/import use the "Node Export" module.
Useful links :
Upgrade process
Migrating D6 Content Construction Kit (CCK) to D7 Fields
Upgrading a drupal site from a major version to the next one is a challenging task, no matter how "basic" is the site involved. You should definitely do that on a copy of your website in a development environment and deploy the upgraded version only after you have it fully tested.
To do that you most certainly need to have a copy of the site's database: if you can't access the db server directly you can try one of a number of modules that can help you to do that (e.g. http://drupal.org/project/dumper).
You need to read the upgrade guide thoroughly (http://drupal.org/documentation/upgrade/6/7 and follow all the links).
And, as CivicCRM actually has a Drupal 6 version, you might want to consider to stick with D6...
I'm trying to write a module that requires either module a or module b (not both, though having both is fine). It just dependent on a OR b. Is there a way to put this in the .info file or enforce this OR dependency programatically?
You can't natively in any current version of Drupal, there is a discussion here which talks about adding a enhances[] and enhancedby[] property for .info files (amongst a few other new properties), but it has not been put into core as far as I can tell.
If you're using Drupal 6 you might have a look at the Module Supports module which was created in response to that discussion.
If you're using Drupal 7 the discussion might get you half way there, and if not there are a few patches on that page that will at least show you roughly what you need to do to patch Drupal core yourself to do get it working.
The only way I've seen other modules implement this is by reporting problems after a module is installed and not including the modules as dependent. I would assume this would be similar to modules like ckeditor or jquery_ui which require non-drupal code to be put in place to operate properly.
When I was upgrding my webite from drupal 4.7 to 5.2, I am facing an issue -
Fatal error: Call to undefined function node_get_base() in ../question.module.
Can any one help me to solve it...
Thanks in advance
The root of your problem is that you have some code in the file question.module calling a deprecated function (node_get_base()). Drupal 5.2 does not implement anymore that function so you get the error...
I assume that the question.module you are using is this one, which does exist for Drupal 5 series. If I am right, then I suspect you have missed to follow the upgrade instructions for updating your site which state:
5) Disable all custom and contributed modules.
[..]
11) Ensure that the versions of all custom and contributed modules match the new Drupal version to which you have updated. For a major update, such as from 5.x to 6.x, modules from previous versions will not be compatible and updated versions will be required.
12) Re-enable custom and contributed modules and re-run update.php to update custom and contributed database tables.
These instructions are in the UPGRADE.txt file in the Drupal root folder.
Hope this helps!
When upgrading Drupal to a new release, you more or less in some respects have to build the site over again. The thing is, that because the Drupal API changes to much in the new releases, each module will need to be replaced with a new one. In most cases this is just a matter of downloading a new version of the module and running update.php.
You should, however, go through each of your modules and find out what's needed to make the upgrade. Sometimes the upgrade path can be a bit tricky and you need a few attempts to get it right without corrupting any data in the process.
Another thing is, that when upgrading, going for the drupal 5 version of the same module might not always be the best choice. Especially when talking about Drupal 5, there are a lot of more or less unmaintained modules. So the best choice might be to find a different module that can do what you want, or even fulfill more of your needs.
It's always a hard decision and your theme will also need to be upgraded to Drupal 5. In short there is a lot of work evolved when doing a major upgrade. Most of it, is making some good choices about, which modules to use and how to migrate your data.
All that aside, following the upgrade guide in UPGRADE.txt like mac suggests is a very good place to start, and doing all of this leg work, would probably have avoided all this.
When I create a new Drupal site I usually end up with at least one custom module and several community contributed modules. To get the site working as it should, many configuration values need to be set on the various modules. This makes deployment onto a fresh Drupal instance painstaking and error-prone.
I would like to give my custom module the ability to configure all the other modules. Either on install or on the click of a button on my custom module's administration page, all the necessary configuration values on the other modules would be programmatically set.
How would I best go about doing this?
AFAIK, there's no way to achieve what you mean easily. I tend to put as much as I can in hook_update_N() implementations and do frequent DB synchronisations as described in my answer to this question. However that does not work when you already have a live server with which you will have to merge data.
To that purpose, I use various tools according to the need. No one is perfect, but here's however a small collection of my favorite ones:
Features. This is a new concept and a new module. The idea is pretty awesome: it allows you to define a set of configuration/modules/settings and to export them as a feature. This feature will then be installed as if it were a module on the target site. This module does not export every possible setting, but it does however do a good job with the modules that need the hardest configuration, as CCK, Views, ImageCache and others... You can see a screencast demo (~10 mins) here.
Backup and migrate. This is a more radical approach: it simply dump and rebuild the entire database on a target system. It is good only if you need to overwrite the target system completely.
Node export. This allows to export (and import) nodes from a drupal installation to another one. It supports bulk operations but - unluckily - it does not support the migration of attached files and images.
Deploy. Because of the limitations of node export I once looked into using this module (still in development). I finally did not, and preferred to do a merge of the production and staging databases, but the concept seems very valid, as it allows to import/export complex data type via SOAP.
Taxonomy import/export. I suppose the name is self-explanatory. It uses files to achieve the tasks (XML or CSV).
Installation profiles (suggested by ctford) are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles. The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.
Finally, you can find a collection of tools for importing/exporting data here.
HTH!
have you looked at the "features" module? it is a new paradigm introduced as part of the open atrium distribution but also available as a stand-alone module. from their description:
"The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.
Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically."
http://drupal.org/project/features
Installation profiles are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles.
The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.
I know what you mean, it's a pain to set all modules up.
I'm sure you can investigate all 3rd party modules to see how configuration takes place and mimic that in your custom module, but I'd advise you against that...
The problem is that modules may change the way they store their settings from one revision to another, so whenever you update to a new version of any module you should do some reverse-engineering to see if your 'ultimate-one-click-configuration module' still works ok - which, if you ask me, is even more painful than manually configuring all modules for each project.
Just relax, take it easy, and enjoy Drupal :)
As the initialization is only required when Drupal is installed, I would think that a installation profile is the better solution; to keep a module that is not anymore used once that the installation is configured seems a little excessive, IMO.
Changing the installation profile used from a site, and make the new installation profile run its installation code isn't something that Drupal allows out-of-the-box. I would create a custom installation profile before creating the sites I need, and only for the features I know all the sites will share. For the other features, I would create separate custom modules I can later install, and eventually uninstall when the features they implement aren't anymore necessary.