View Categories

App Administration

12 min read

Multilingual Feature

This document describes the implementation of multilingual features.

Scope

The scope of this feature is as follows.

  • Adding a dropdown to switch between the languages.
  • The user should be able to add/modify translations
  • The user should be able to define the content translations & config translation
  • Users will be able to add new languages.
  • How to make the site translatable and how to make the entity and fields translatable?

Introduction

The Multilingual Feature in RTE-MIS allows us to transcend language barriers, providing users a seamless and localized experience. This documentation is a comprehensive guide for developers and administrators, offering step-by-step instructions, best practices, and key insights into the integration of multilingual capabilities within the Drupal framework.

Overview

  • Content Translation: Learn how to leverage content translation capabilities to create and manage multilingual content, ensuring that materials are accessible in multiple languages.
  • Language Switching: Explore methods for enabling smooth language switching mechanisms, allowing users to seamlessly navigate between different language versions of the RTE-MIS website.
  • Localization Best Practices: Dive into best practices for localizing various elements, to enhance the overall user experience.

Installation and Configuration

  • Module Installation
    • The multilingual feature in RTE-MIS relies on several core modules to seamlessly configure language-related settings. Ensure the following modules are installed and enabled in your Drupal instance:
      • Language: Core module for language handling and configuration.
      • Locale: Core module for providing translated versions of the user interface.
      • Content Translation: Core module allowing translation of content entities.
      • Config Translation: Core module for translating configuration entities.
    • These modules can be enabled through the Drupal administrative interface or by utilizing Drush commands. Verify their status by navigating to Extend (Configuration -> Extend) and ensuring that the mentioned modules are enabled.

# Drush command to enable modules:

  • drush en language locale content_translation config_translation -y
  • Language Configuration
    • Once the multilingual modules are enabled, proceed with the configuration:
    • Navigate to Language settings: Configuration -> Region and language -> Languages.
    • To add a new language to your RTE-MIS instance:
    • On the Languages page, click on the Add Language button.
    • Select the desired language from the list of available languages. You can search for a specific language or scroll through the options.
    • Click the Add Language button to confirm your selection.
    • Optionally, set the newly added language as the site’s default language using the “Make default” link next to the language.
  • Making Entity Types Translatable
    • Go to Content language and translation: Configuration -> Region and language -> Content language and translation.
    • On the Content Language and Translation page, choose the entity types that you want to make translatable. In the case of RTE-MIS, select the following entity types:
      • Content type: This includes various content entities on your site.
      • Taxonomy Term: For translating taxonomy terms used in categorizing content.
      • URL Alias: For translating URL aliases used for different language versions of pages.
    • For each selected entity type (Content, Taxonomy Term, and URL Alias), further specify the bundles or fields that need to be translatable.
  • Adding Language Dropdown on Page: To enhance the user experience and provide seamless language-switching capabilities, RTE-MIS incorporates the Language Switcher Dropdown module. Follow the steps outlined below to integrate and configure the language dropdown on your site:
    • Install the module using Composer:

composer require drupal/lang_dropdown

  • Enable the module using Drush or through the Extend (admin/modules) page

drush en lang_dropdown -y

  • Placing Language Dropdown Block
    • Once the Language Switcher Dropdown module is enabled, proceed to configure and place the language dropdown block
    • Navigate to Block Layout: Structure -> Block Layout.
    • Click on Place Block within the desired region (e.g., header) where you want to display the language dropdown.
    • Search for and select the Language dropdown switcher block from the list.
    • Click the Place Block button to add the block to the selected region.

Usage

  • Accessing the User Interface Translation Page
    • Navigate to the User Interface Translation page to manage and translate strings
    • Go to User interface translation: Configuration -> Region and language -> User interface translation.
    • On the User Interface Translation page, you will find a comprehensive list of all strings used in the site interface, categorized by their translation status:
      • Translated Strings: Strings that have already been translated into at least one language.
      • Un-translated Strings: Strings that have not yet been translated and are displayed in the default language.
    • Here, you can easily manage and alter these strings to customize the site interface according to your language preferences.
  • Adding a New Language
    • Navigate to Language Settings
    • From the admin menu, access Language settings: Configuration -> Region and language -> Languages.
    • Click on “Add language”
    • Select the Desired Language
    • Set Default Language (Optional)
    • On the Languages page, locate the newly added language.

Best Practices

  • Utilize Language Codes – Use standardized language codes (ISO 639-1 or ISO 639-2) when adding new languages. This ensures consistency and compatibility across different systems.
  •  Implement Language-Specific URLs – Enable language-specific URLs for better SEO and user experience. This helps search engines index different language versions and allows users to share and bookmark pages in their preferred language.
  • Regularly Update Translations – Keep translations up-to-date as content evolves. Regularly review and update translated content to maintain accuracy and relevance across all language versions.
  • It is recommended that the custom code should be wrapped in the translates method t().

References

Versioning and Updates

# For minor/patch release.

  • composer update drupal/lang_dropdown -w

# For major version release.

  • composer require drupal/lang_dropdown:^new_version

# Execute the update hooks using drush.

  • drush updb

# Export the configuration using drush.

  • drush cex

Feedback and Support

SMS & EMAIL SERVICES

Introduction

The Email and SMS validation is an optional but important feature in the RTE-MIS portal. This document serves as a comprehensive guide on how the development team has implemented the email & sms services for School Admins. It highlights key aspects such as field descriptions, validation mechanisms, and submission procedures.

Prerequisites

  • Access to a Drupal 10+ environment with appropriate permissions.
  • Installation of necessary modules
    • Contrib Modules: Mobile Number, SMSFramework module, Gateway Module(If you require any custom gateway).
    • Custom Modules:  rte_mis_school, rte_mis_mail.

Installation and Configuration

  • To ensure the proper functioning of the Register form along with all validations, it’s essential to have several contributed and custom modules installed and enabled in your Drupal instance. Please ensure the modules mentioned in the Prerequisites are installed and enabled.
  • To enable a module in the Drupal instance using Drush, use

drush en module_name

Replace the module name with the actual name of the module. For example

To enable the password policy module use.

drush en password_policy

Email Address Validation

  • Introduction

The Email field is a pivotal component within the Register Form of the Drupal system. It is a required field, provided by Drupal core itself, yet it is customized to meet our specific requirements. Administrators can configure the validation settings for this field, providing flexibility in the registration process.

  • Modules used

Custom Module: rte_mis_mail

  • Development Process
    • We have developed a custom module where we extended Drupal’s default register form to include additional functionality. Specifically, we added a form accessible via the path /admin/config/system/settings, where the App Admin user can enable the verification option. To achieve this, we utilized Drupal’s hook system, specifically hook_form_id_alter, to modify the existing Drupal validation process. 
    • Upon enabling the verification option by the App Admin user, an additional button labeled as ‘Verify Email’ is displayed below the email field in the register form of the School Admin User. Upon clicking this button, the email field is set to read-only, and an AJAX call is triggered to generate and send an OTP (One-Time Password) to the registered email address. Subsequently, three new fields appear: ‘Enter OTP‘ (a text field) and two buttons labeled ‘Submit OTP‘ and ‘Resend OTP‘.
    • After entering the OTP in the ‘Enter OTP’ field, another AJAX call is triggered which verifies the OTP against the records stored in the otp_table. If the entered OTP matches the one sent to the user(stored in the database), the account creation process proceeds. Otherwise, an error message is displayed indicating that the OTP did not match. Additionally, users have the option to resend the OTP in case they did not receive it initially or need to request a new one for any reason. But there is flood control implemented, they can resend the OTP only after 30 seconds from the time they requested the OTP. They can send the OTP or request to resend OTP, a maximum of 5 times.

1. OTP verification enabled.

2. OTP send.

3. When OTP is resent.



4. When email is verified.

  • Conclusion

This implementation provides an enhanced registration process with email verification, ensuring the security and integrity of user accounts on the Drupal website.

Mobile Number Validation

  • Introduction

The Phone Number field is a required field of user registration within the Drupal system. This documentation provides comprehensive details on the configuration and functionality of the Phone Number field’s validation settings, including SMS gateway integration, validation process, and configuration options.

  • Modules Used

Contrib Modules used: Mobile Number Field, SmsFramework

  • Development Process

We have leveraged the Mobile Number Field module in our system, which offers a specialized field type capable of generating, storing, and validating OTPs (One-Time Passwords). However, to send these OTPs to users, we have seamlessly integrated the SMSFramework module. This integration allows us to utilize various SMS gateways for OTP delivery. Additionally, we have implemented a custom hook_form_id_alter() to facilitate a counter feature, allowing users to request OTPs multiple times. Users can request a new OTP after a 30-second interval.

By default, our system provides the option to use the Drupal logger as a gateway. In this configuration, all SMS messages the system triggers will be stored in Drupal’s default logger. Additionally, we offer the flexibility to integrate alternative gateways, such as the Fast2sms gateway module, to cater to specific needs and preferences.

To further enhance the customization and management of this functionality, we have implemented a configuration form accessible to App Admin users. This form includes two essential fields:

  • Checkbox Field (Allow SMS Validation)
    • This checkbox allows App Admin users to enable or disable the SMS validation feature.
    • When enabled, users will be prompted to verify their mobile numbers via SMS during the registration process.
  • Text Field (Message Configuration)
    • In this field, App Admin users can configure the message content that accompanies the OTP sent to users. This is a text field.
    • The message can be personalized, including instructions, branding elements, or relevant information.

1. When validation is disabled.

                            2. When SMS validation is enabled.

                       3. When OTP is sent.

                       4. When the phone number is verified.
   

  • Conclusion

This implementation enriches the registration process with mobile number verification, bolstering the security and reliability of user accounts on the Drupal website. By integrating the Mobile Number Field module and SMSFramework, we offer users an additional layer of authentication, strengthening account protection against unauthorized access. This verification mechanism enhances user confidence in the platform’s security measures and fosters a more secure online environment. Additionally, the flexibility provided by the configuration options allows administrators to customize the validation process according to specific organizational needs, ensuring seamless integration and user experience.

Customization and Extensibility 

  • For custom modules, we can modify the code as per requirements.
  • For the control modules, we can create custom patches and use them to serve the purpose.

Troubleshooting 

  • If the verification for the mobile number field is enabled then the School Admin user must verify their mobile number by sending and validating it in the register form. 
  • If the verification for the email field is enabled then the School Admin user must verify their email by sending and validating it in the register form. Users also have the option to resend OTP in case of any issue.

Best Practices 

  • Encourage users to verify the accuracy of the entered information before submitting the registration form.
  • Email verification is an optional feature but if it’s enabled, School Admin users should verify the email address.
  • Mobile number verification is an optional feature but if it’s enabled, School Admin users should verify the mobile number by sending SMS.
  • Regularly update and maintain the Drupal environment and associated modules to ensure optimal performance and security.

References 

Versioning and Updates 

  • The register form from Drupal Core works well with all the versions. However, the custom modules are compatible with Drupal 10+.

Feedback and Support