Translate a Drupal 7 custom module via l10n_update

It is really a big deal to manage translations of custom module in Drupal 7 expecially if you have a multisite installation.

Problem

We want use a .po file to translate a custom module programmatically, i.e. without forcing a redactor to do dangerous manual operations.

Furthermore we want have our module always accompained by its translations.

Solution

First of all we need to have l10n_update module installed.

Than we can declare the hook “l10n_update_projects_alter” which allow to set a remote path where the .po file is hosted.

Normally the path should be a remote, indipendent one, but in most cases we would like to have the .po file inside the website itself (i.e. not a separeted environment).

Take a look to the code below in which I declare a .po file that is in the module folder, in particular in “translations” subfolder.

As you can see the file name contains the parameter %language. In this case the filename would be ModuleName.LanguageCode.po.

/**
 * Alter the list of project to be updated by Localization Update.
 *
 * L10n_update uses the same list of projects as update module. Using this hook
 * the list can be altered. This hook is typically used to alter the following
 * values from the .info file:
 *  - interface translation project
 *  - l10n path.
 *
 * @param array $projects
 *   Array of projects.
 */
function my_module_name_l10n_update_projects_alter(array &$projects) {
  // Setting module name.
  $name = 'my_module_name';
  // Setting the path of .po files.
  $pathToModule = drupal_get_path('module', $name);
  $pathToPo = $pathToModule . '/translations/';
  $poFileName = $name . '.%language.po';
  // Getting url to po
  $urlToPoFolder = file_create_url($pathToPo);
  $urlToPoFile = $urlToPoFolder . $poFileName;

  /**
   * In case of S3 filesystem uncomment the code below.
   */
  // Instead of the default ftp.drupal.org we use the file system of the test
  // instance to simulate a remote file location.
  //$wrapper = file_stream_wrapper_get_instance_by_uri('public://');
  //$remote_url = $wrapper->getExternalUrl() . '/remote/';

  // With this hook it is also possible to add a new project which does not
  // exist as a real module or theme project but is treated by the localization
  // update module as one. The below data is the minimum to be specified.
  // As in the previous example the 'l10n path' element is optional.
  $projects[$name] = array(
    'project_type'  => 'module',
    'name' => $name,
    'info' => array(
      'name' => 'My Module name',
      'interface translation project' => $name,
      'version' => '7.x-1.0',
      'core' => '7.x',
      'l10n path' => $urlToPoFile,
    ),
  );
}

Furthermore with the following snippet, I have manually (i.e. programmatically) forced the module to update its translations.

// Getting dependencies.
module_load_include('inc','l10n_update','l10n_update.translation');
module_load_include('inc','l10n_update','l10n_update.fetch');


$projects = ['my_module_name'];


$options = _l10n_update_default_update_options();
$options['customized'] = true;
$options['use_remote'] = true;
$options['overwrite_options']['customized'] = true;

l10n_update_clear_status();
$batch = l10n_update_batch_update_build($projects, [], $options);
batch_set($batch);

The .po files have been extracted thanks to Translation Template Extractor.

jQuery Once: Drupal 8 vs Drupal 7

utilities:
  version: 1.x
  js:
    js/throbber.js: {}
  dependencies:
  - core/drupalSettings
  - core/jquery
  - core/jquery.once

 

Chi ha avuto modo di cimentarsi nella stesura di qualche riga di codice JS in Drupal 8 si sarà sicuramente imbattuto in un problema, quello di jQuery once che non funziona a dovere, o almeno così pare.

Cosa è successo?

In primis c’è da capire qual è la versione di jQuery utilizzata.

Drupal 7

In tal senso con il modulo contrib jQuery update di Drupal 7 era possibile passare dalla versione 1.4 di jQuery ad una versione superiore a scelta (oggi arrivata alla 1.10) e che il modulo non è più disponibile in Drupal 8.

In Drupal 7 avremmo fatto una cosa del genere:

# source: https://www.drupal.org/node/2457769
/**
 * Attach my behavior to the .mybehavior elements.
 */
Drupal.behaviors.mybehavior = {
  attach: function(context) {
    // Set the initial state of the toolbar.
    $('.mybehavior', context).once('mybehavior', function() {
      // Do something to the elements.
      $(this).css('background-color', 'red');
    });
  }
};

Drupal 8

In Drupal 8 la versione di jQuery è la 3.2.1 (questo al 24/07/2018 quando è appena uscita l’alpha di Drupal 8.6.0-alpha1; vedi immagine).

Quindi molto più avanzata rispetto a quella di Drupal 7.

Questo ha fatto sì che il modo di invocare determinate funzioni (come il once) sia cambiato.

Come rilevato nel ticket aperto dalla community di Drupal c’è un problema di funzionamento con jQuery once che deve essere invocato in un altro modo, dopo che esso è stato aggiornato alla versione 2.0.

Ebbene tutto ciò è stato realizzato discusso, analizzato e risolto in un ticket sulla community, questo: https://www.drupal.org/node/2457769.

Per comodità riporto di seguito l’esempio ivi riportato:

# source: https://www.drupal.org/node/2457769
/**
 * Attach my behavior to the .mybehavior elements.
 */
Drupal.behaviors.mybehavior = {
  attach: function(context) {
    // Set the initial state of the toolbar.
    $(context).find('[data-mybehavior]').once('mybehavior').each(function() {
      // Do something to the elements.
      $(this).css('background-color', 'red');
    });
  }
};

Come è possibile vedere adesso il once si ottiene in maniera sequenziale, senza gli innesti che erano necessari qualche versione fa.

EDIT 08/01/2019

Per evitare che l’utente anonimo abbia problemi con jQuery Once è necessario includere quanto segue, tra le dipendenze di un modulo che usa jQuery Once.

Riferimento: https://www.drupal.org/project/ultimenu/issues/2562829

 

Drupal 7 campi condizionali nei form con gli states

Oggi voglio presentarvi gli states degli elementi di un form Drupal.

Il problema

Vogliamo per un motivo o per un altro nascondere selettivamente dei campi in determinate condizioni, senza scrivere dei JS da aggiungere al form, massimizzando la manutenibilità del codice.

Tutto questo è consentito dagli states degli elementi del form di Drupal che consentono di inserire una logica con stati e condizioni in grado ad esempio di nascondere un campo se una checkbox è flaggata oppure mostrare un campo e renderlo obbligatorio.

Esempio:

Poniamoci nel caso in cui abbiamo un modulo di inserimento (un form insomma) di richieste di supporto in cui abbiamo un campo di tipo select chiamato “Oggetto” con varie opzioni selezionabili. Una di queste opzioni è “Altro”, se “Altro” è selezionato allora bisogna mostrare un campo (normalmente nascosto) chiamato “oggetto altro”.

Un codice di questo tipo risolve assolve al compito:

$form['subject_other'] = array(
  '#states' => array(
    // Show the subject_other if subject value is other.
    'visible' => array(
      ':input[name="subject"]' => array('value' => 'other'),
    ),
    'required' => array(
      ':input[name="subject"]' => array('value' => 'other'),
    ),
  ),
);

Interessante analizzare la funzione drupal_process_states poiché essa mostra tutti gli stati e le condizioni possibili, che per comodità riporto qui sotto:

I possibili stati di un elemento (del form) sono:

  • enabled
  • disabled
  • required
  • optional
  • visible
  • invisible
  • checked
  • unchecked
  • expanded
  • collapsed

Le possibili condizioni (che su drupal.org chiama remote conditions) sono:

  • empty
  • filled
  • checked
  • unchecked
  • expanded
  • collapsed
  • value

Gli stati che seguono possono essere utilizzati sia come stati di un elemento (primo gruppo) sia come condizioni remote (secondo gruppo):

  • relevant
  • irrelevant
  • valid
  • invalid
  • touched
  • untouched
  • readwrite
  • readonly

Tuttavia il funzionamento di quest’ultimo gruppo di stati non è garantito in ogni scenario, poiché le funzionalità che ne derivano sono molto dipendenti dal browser dal quale vengono eseguite.

Dalla versione 7.14 di Drupal è anche possibile usare OR e XOR.

Spero di essere stato utile.

NOTA: Un discorso del tutto analogo può essere fatto per Drupal 8 che, sebbene abbia stravolto la maggior parte delle funzionalità di Drupal 7, implementa questa degli states degli elementi del form in maniera similare.