Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 21 hours 33 min ago

Cheeky Monkey Media: Module Mayhem in the Drupal Kitchen

29 August 2019 - 10:31am
Module Mayhem in the Drupal Kitchen kodie Thu, 08/29/2019 - 17:31

In my opinion, there’s nothing in the world quite like learning a new skill. It’s a huge rush figuring out how to do something you didn’t know how to do before. You start with the basics, and then once you’ve got the gist of it, you begin to improve. Over time you’ll get better at it, and you’ll get faster at it. Aside from just improving your abilities, your confidence level might change too. This process can go a few different ways. One is imposter syndrome, where you feel like a fraud that doesn’t know what they’re doing. The other is overconfidence, where you think that your skills are better than they are. Be it due to imposter syndrome, overconfidence, or just plain ol’ inexperience; you’re bound to make some mistakes. And we don’t wanna make mistakes, do we?

Categories: Drupal

Hook 42: Quickly Find out What’s Being Processed in Your Migration Pipeline

29 August 2019 - 7:55am
Quickly Find out What’s Being Processed in Your Migration Pipeline Darryl Richman Thu, 08/29/2019 - 14:55
Categories: Drupal

Code Karate: Generating A Module with Drupal Console

29 August 2019 - 6:59am
Episode Number: 225

Drupal Console is a command line tool for Drupal (similar to Drush) that has built in code generation tools. This makes it easy to generate boilerplate code for a custom Drupal 8 module. In this episode, we discuss how to use Drupal Console to generate an example module with an administrative settings form.

Tags: DrupalFormsDrupal 8Module DevelopmentDrupal Planet
Categories: Drupal

Agiledrop.com Blog: Agiledrop recognized as a top Drupal development company by TopDevelopers.co

29 August 2019 - 1:11am

In a recent press release, TopDevelopers.co declared Agiledrop one of 2019’s best Drupal development firms in the world. With over 10 years of extensive Drupal expertise and several Acquia certified developers, we see this recognition as a true testament to the quality of our work, both with clients and within the Drupal community.

READ MORE
Categories: Drupal

Agaric Collective: Using migration groups to share configuration among Drupal migrations

28 August 2019 - 8:48pm

In the previous posts we talked about option to manage migrations as configuration entities and some of the benefits this brings. Today, we are going to learn another useful feature provided by the Migrate Plus module: migration groups. We are going to see how they can be used to execute migrations together and share configuration among them. Let’s get started.

Understanding migration groups

The Migrate Plus module defines a new configuration entity called migration group. When the module is enabled, each migration can define one group they belong to. This serves two purposes:

  1. It is possible to execute operations per group. For example, you can import or rollback all migrations in the same group with one Drush command provided by the Migrate Tools module.
  2. It is is possible to declare shared configuration for all the migrations within a group. For example, if they use the same source file, the value can be set in a single place: the migration group.

To demonstrate how to leverage migration groups, we will convert the CSV source example to use migrations defined as configuration and groups. You can get the full code example at https://github.com/dinarcon/ud_migrations The module to enable is UD configuration group migration (CSV source) whose machine name is ud_migrations_config_group_csv_source. It comes with three migrations: udm_config_group_csv_source_paragraph, udm_config_group_csv_source_image, and  udm_config_group_csv_source_node. Additionally, the demo module provides the udm_config_group_csv_source group.

Note: The Migrate Tools module provides a user interface for managing migrations defined as configuration. It is available under “Structure > Migrations” at /admin/structure/migrate. This user interface will be explained in a future entry. For today’s example, it is assumed that migrations are executed using the Drush commands provided by Migrate Plus. In the past we have used the Migrate Run module to execute migrations, but this module does not offer the ability to import or rollback migrations per group.

Creating a migration group

The migration groups are defined in YAML files using the following naming convention: migrate_plus.migration_group.[migration_group_id].yml. Because they are configuration entities, they need to be placed in the config/install directory of your module. Files placed in that directory following that pattern will be synced into Drupal’s active configuration when the module is installed for the first time (only). If you need to update the migration groups, you make the modifications to the files and then sync the configuration again. More details on this workflow can be found in this article. The following snippet shows an example migration group:

uuid: e88e28cc-94e4-4039-ae37-c1e3217fc0c4 id: udm_config_group_csv_source label: 'UD Config Group (CSV source)' description: 'A container for migrations about individuals and their favorite books. Learn more at https://understanddrupal.com/migrations.' source_type: 'CSV resource' shared_configuration: null

The uuid key is optional. If not set, the configuration management system will create one automatically and assign it to the migration group. Setting one simplifies the workflow for updating configuration entities as explained in this article. The id key is required. Its value is used to associate individual migrations to this particular group.

The label, description, and source_type keys are used to give details about the migration. Their value appear in the user interface provided by Migrate Tools. label is required and serves as the name of the group. description is optional and provides more information about the group. source_type is optional and gives context about the type of source you are migrating from. For example, "Drupal 7", "WordPress", "CSV file", etc.

To associate a migration to a group, set the migration_group key in the migration definition file: For example:

uuid: 97179435-ca90-434b-abe0-57188a73a0bf id: udm_config_group_csv_source_node label: 'UD configuration host node migration for migration group example (CSV source)' migration_group: udm_config_group_csv_source source: ... process: ... destination: ... migration_dependencies: ...

Note that if you omit the migration_group key, it will default to a null value meaning the migration is not associated with any group. You will still be able to execute the migration from the command line, but it will not appear in the user interface provided by Migrate Tools. If you want the migration to be available in the user interface without creating a new group, you can set the migration_group key to default. This group is automatically created by Migrate Plus and can be used as a generic container for migrations.

Organizing and executing migrations

Migration groups are used to organize migrations. Migration projects usually involve several types of elements to import. For example, book reports, events, subscriptions, user accounts, etc. Each of them might require multiple migrations to be completed. Let’s consider a news articles migration. The "book report" content type has many entity reference fields: book cover (image), support documents (file), tags (taxonomy term), author (user), citations (paragraphs). In this case, you will have one primary node migration that depends on five migrations of multiple types. You can put all of them in the same group and execute them together.

It is very important not to confuse migration groups with migration dependencies. In the previous example, the primary book report node migration should still list all its dependencies in the migration_dependencies section of its definition file. Otherwise, there is no guarantee that the five migrations it depends on will be executed in advance. This could cause problems if the primary node migration is executed before images, files, taxonomy terms, users, or paragraphs have already been imported into the system.

It is possible to execute all migrations in a group by issuing a single Drush with the --group flag. This is supported by the import and rollback commands exposed by Migrate Tools. For example, drush migrate:import --group='udm_config_group_csv_source'. Note that as of this writing, there is no way to run all migrations in a group in a single operation from the user interface. You could import the main migration and the system will make sure that if any explicit dependency is set, they will be run in advance. If the group contained more migrations than the ones listed as dependencies, those will not be imported. Moreover, migration dependencies are only executed automatically for import operations. Dependent migrations will not be rolled back automatically if the main migration is rolled back individually.

Note: This example assumes you are using Drush to execute the migrations. At the time of this writing, it is not possible to rollback a CSV migration from the user interface. See this issue in the Migrate Source CSV for more context.

Sharing configuration with migration groups

Arguably, the major benefit of migration groups is the ability to share configuration among migrations. In the example, there are three migrations all reading from CSV files. Some configurations like the source plugin and header_offset can be shared. The following snippet shows an example of declaring shared configuration in the migration group for the CSV example:

uuid: e88e28cc-94e4-4039-ae37-c1e3217fc0c4 id: udm_config_group_csv_source label: 'UD Config Group (CSV source)' description: 'A container for migrations about individuals and their favorite books. Learn more at https://understanddrupal.com/migrations.' source_type: 'CSV resource' shared_configuration: dependencies: enforced: module: - ud_migrations_config_group_csv_source migration_tags: - UD Config Group (CSV Source) - UD Example source: plugin: csv # It is assumed that CSV files do not contain a headers row. This can be # overridden for migrations where that is not the case. header_offset: null

Any configuration that can be set in a regular migration definition file can be set under the shared_configuration key. When the migrate system loads the migration, it will read the migration group it belongs to, and pull any shared configuration that is defined. If both the migration and the group provide a value for the same key, the one defined in the migration definition file will override the one set in the migration group. If a key only exists in the group, it will be added to the migration when the definition file is loaded.

In the example, dependencies, migration_tag, and source options are being set. They will apply to all migrations that belong to the udm_config_group_csv_source group. If you updated any of these values, the changes would propagate to every migration in the group. Remember that you would need to sync the migration group configuration for the update to take effect. You can do that with partial configuration imports as explained in this article.

Any configuration set in the group can be overridden in specific migrations. In the example, the header_offset is set to null which means the CSV files do not contain a header row. The node migration uses a CSV file that contains a header row so that configuration needs to be redeclared. The following snippet shows how to do it:

uuid: 97179435-ca90-434b-abe0-57188a73a0bf id: udm_config_group_csv_source_node label: 'UD configuration host node migration for migration group example (CSV source)' # Any configuration defined in the migration group can be overridden here # by re-declaring the configuration and assigning a value. # dependencies inherited from migration group. # migration_tags inherited from migration group. migration_group: udm_config_group_csv_source source: # plugin inherited from migration group. path: modules/custom/ud_migrations/ud_migrations_csv_source/sources/udm_people.csv ids: [unique_id] # This overrides the header_offset defined in the group. The referenced CSV # file includes headers in the first row. Thus, a value of 0 is used. header_offset: 0 process: ... destination: ... migration_dependencies: ...

Another example would be multiple migrations reading from a remote JSON. Let’s say that instead of fetching a remote file, you want to read a local file. The only file you would have to update is the migration group. Change the data_fetcher_plugin key to file and the urls array to the path to the local file. You can try this with the ud_migrations_config_group_json_source module from the demo repository.

What did you learn in today’s blog post? Did the know that migration groups can be used to share configuration among different migrations? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors. Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at agaric.coop.

Categories: Drupal

Agaric Collective: What is the difference between migration tags and migration groups in Drupal?

28 August 2019 - 8:47pm

In the previous post we talked about migration groups provided by the Migrate Plus module. Today, we are going to compare them to migration tags. Along the way, we are going to dive deeper into how they work and provide tips to avoid problems when working with them. Let’s get started.

What is the difference between migration tags and migration groups?

In the article on declaring migration dependencies we briefly touched on the topic of tags. Here is a summary of migration tags:

  • They are a feature provided by the core Migrate API.
  • Multiple tags can be assigned to a single migration.
  • They are defined in the migration definition file alone and do not require creating a separate file.
  • Both Migrate Tools and Migrate Run provide a flag to execute operations by tag.
  • They do not allow you to share configuration among migrations tagged with the same value.

Here is a summary of migration groups:

  • You need to install the Migrate Plus module to take advantage of them.
  • Only one group can be assigned to any migration.
  • You need to create a separate file to declare group. This affects the readability of migrations as their configuration will be spread over two files.
  • Only the Migrate Tools provides a flag to execute operations by group.
  • They offer the possibility to share configuration among members of the same group.
  • Any shared configuration could be overridden in the individual migration definition files.
What do migration tags and groups have in common?

The ability to put together multiple migrations under a single name. This name can be used to import or rollback all the associated migrations in one operation. This is true for the migrate:import and migrate:rollback Drush commands provided by Migrate Plus. What you have to do is use the --group or --tag flags, respectively. The following snipped shows an example of importing and rolling back the migrations by group and tag:

$ drush migrate:import --tag='UD Config Group (JSON Source)' $ drush migrate:rollback --tag='UD Config Group (JSON Source)' $ drush migrate:import --group='udm_config_group_json_source' $ drush migrate:rollback --group='udm_config_group_json_source'

Note: You might get errors indicating that the "--tag" or "--group" options do not accept a value. See this issue if you experience that problem.

Neither migration tags nor groups replace migration dependencies. If there are explicit migration dependencies among the members of a tag or group, the Migrate API will determine the order in which the migrations need to be executed. But if no dependencies are explicitly set, there is no guarantee the migrations will be executed in any particular order. Keep this in mind if you have separate migrations for entities that you later use to populate entity reference fields. Also note that migration dependencies are only executed automatically for import operations. Dependent migrations will not be rolled back automatically if the main migration is rolled back individually.

Can groups only be used for migrations defined as configuration entities?

Technically speaking, no. It is possible to use groups for migrations defined as code. Notwithstanding, migration groups can only be created as configuration entities. You would have to rebuild caches and sync configuration for changes in the migrations and groups to take effect, respectively. This is error prone and can lead to hard to debug issues.

Also, things might get confusing when executing migrations. The user interface provided by Migrate Plus works exclusively with migrations defined as configuration entities. The Drush commands provided by the same module work for both types of migrations: code and configuration. The default and null values for the migration_group key are handled a bit different between the user interface and the Drush commands. Moreover, the ability to execute operations per group using Drush commands is provided only by the Migrate Tools module. The Migrate Run module lacks this functionality.

Managing migrations as code or configuration should be a decision to take at the start of the project. If you want to use migration groups, or some of the other benefits provided by migrations defined as configuration, stick to them since the very beginning. It is possible to change at any point and the transition is straightforward. But it should be avoided if possible. In any case, try not to mix both workflows in a single project.

Tip: It is recommended to read this article to learn more about the difference between managing migrations as code or configuration.

Setting migration tags inside migration groups

As seen in this article, it is possible to use set migration tags as part of the shared configuration of a group. If you do this, it is not recommended to override the migration_tags key in individual migrations. The end result might not be what you expect. Consider the following snippets as example:

# Migration group configuration entity definition. # File: migrate_plus.migration_group.udm_config_group_json_source.yml uuid: 78925705-a799-4749-99c9-a1725fb54def id: udm_config_group_json_source label: 'UD Config Group (JSON source)' description: 'A container for migrations about individuals and their favorite books. Learn more at https://understanddrupal.com/migrations.' source_type: 'JSON resource' migration_tags: - UD Config Group (JSON Source) - UD Example # Migration configuration entity definition. # File: migrate_plus.migration.udm_config_group_json_source_node.yml uuid: def749e5-3ad7-480f-ba4d-9c7e17e3d789 id: udm_config_group_json_source_node label: 'UD configuration host node migration for migration group example (JSON source)' migration_tags: - UD Lorem Ipsum migration_group: udm_config_group_json_source source: ... process: ... destination: ... migration_dependencies: ...

The group configuration declares two tags: UD Config Group (JSON Source) and UD Example. The migration configuration overrides the tags to a single value UD Lorem Ipsum. What would you expect the final value for the migration_tags key be? Is it a combination of the three tags? Is it only the one key defined in the migration configuration?

The answer in this case is not very intuitive. The final migration will have two tags: UD Lorem Ipsum and UD Example. This has to do with how Migrate Plus merges the configuration from the group into the individual migrations. It uses the array_replace_recursive() PHP function which performs the merge operation based on array keys. In this example, UD Config Group (JSON Source) and UD Lorem Ipsum have the same index in the migration_tags array. Therefore, only one value is preserved in the final result.

The examples uses the migration_tags key as it is the subject of this article, but the same applies to any nested structure. Some configurations are more critical to a migration than a tag or group. Debugging a problem like this can be tricky. But the same applies to any configuration that has a nested structure. If the end result might be ambiguous, it is preferred to avoid the situation in the first place. In general, nested structures should only be set in either the group or the migration definition file, but not both. Additionally, all the recommendations for writing migrations presented in this article also apply here.

What did you learn in today’s blog post? Did you know the difference between migration tags and groups? Share your answers in the comments. Also, I would be grateful if you shared this blog post with others.

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors. Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Read more and discuss at agaric.coop.

Categories: Drupal

Code Karate: Drupal 8 Entity Construction Kit (ECK) Module

28 August 2019 - 6:35pm
Episode Number: 224

The Drupal 8 Entity Construction Kit (ECK) Module allows you to use the Drupal admin interface to build custom entity types. Sometimes you need additional data structures in your Drupal site and it doesn’t make sense to create it as a content type, this is where the ECK module comes in. Using it, you can create your custom entity data structures in Drupal 8 and add fields to them, similarly to how you build out content types.

Tags: DrupalDrupal 8Site BuildingDrupal Planet
Categories: Drupal

Mediacurrent: [Webinar] Usability Testing: How Mass.gov Builds Great Government UX

28 August 2019 - 6:25pm

 

Crafting UX - for the people, by the people 

Mass.gov takes a data-informed approach to site decisions. An open ear to constituent feedback ensures a "wicked awesome" user experience. So it's no surprise that when the site’s navigation needed improvement, user testing became a guiding light.

In our upcoming webinar, hear how Mediacurrent teams with Mass.gov on a user testing strategy leveraging Drupal 8 and Google Optimize. 

Join our webinar

Watch how to deliver a constituent experience that is discoverable, accessible, and truly “for the people, by the people.” Join us on September 18, 2019, at 2:00 EDT to follow along with our process. Learn tips to user test your way to better website UX. 

Register for the webinar.

You'll learn
  • Our approach to testing and gathering user feedback
  • The A/B testing variants we used to steer site navigation and layout
  • Deep dive into testing with Google Optimize 
Presenters
  • Clair Smith, Senior Front End Developer, Mediacurrent
  • Becky Cierpich, UX/UI Designer, Mediacurrent


We hope to see you there!

Categories: Drupal

Lullabot: Level Up Your Twiggery

28 August 2019 - 1:40pm

Drupal 8’s templating language, Twig, provides a powerful suite of tools that often go underutilized. Learning when and where to apply them will empower you to create more readable and DRY code, and allow themers of all experience levels to contribute in a maintainable way.

To highlight some key concepts, let us consider a simple example—wrapping the Article node’s body field in a element. We start with this simple tweak to node--article.html.twig.

Categories: Drupal

Hook 42: Hook 42 is Returning to BADCamp in 2019

28 August 2019 - 12:08pm
Hook 42 is Returning to BADCamp in 2019 Lindsey Gemmill Wed, 08/28/2019 - 19:08
Categories: Drupal

Drudesk: 7 characteristics of a good Drupal support agency

28 August 2019 - 4:12am

To always work smoothly and be up-to-date, your Drupal website needs support and maintenance. It’s nice to know you can rely on experts for things like Drupal updates, website performance audit, bug fixes, or anything else. However, you need to choose them carefully. 

Categories: Drupal

Drupal Association blog: Welcome Carole Bernard to the Drupal Association

27 August 2019 - 11:50am

The Drupal Association (DA) is pleased to announce the recent hire of Carole Bernard as the Director of Marketing and Outreach. She and her team will focus on increasing visibility for the Drupal Association and opportunities for Drupal adoption through marketing, community engagement, volunteer management and public relations activities.

With extensive nonprofit and public sector experience, Bernard has served in senior leadership roles for more than 15 years at local, regional and national organizations.  

Bernard, a Boston native, began her career as a speechwriter for the Mayor of Boston. She then worked as the Director of Public Information for the largest human service agency in New England, Action for Boston Community Development, Inc. She started her own consulting business in 2015, providing strategic communications, fundraising and executive management services to nonprofit organizations in the Washington, DC area. She recently served as the Director of Communications and Marketing for Sickle Cell Disease Association of America, Inc. She also has worked for Paralyzed Veterans of America, National Center for Women and Children and the National Minority AIDS Council as their Director of Communication.

“I am so excited to be a part of the dynamic team at the Drupal Association,” says Bernard. “I am blown away by the passion and commitment of the Drupal community, and I look forward to working with everyone to tell the DA story, to showcase the Drupal project, to broaden the organization’s reach to new audiences and to increase opportunities for Drupal adoption around the world through strategic communications and outreach efforts.”

“We want to continue to position Drupal as the leading open-source CMS for ambitious digital experiences that reach audiences across multiple channels around the world,” says Heather Rocker, DA Executive Director. “We also want to expand our efforts to bring new entities and individuals to the table to participate in our global community. We are excited to have Carole join us and to help us lay out and execute a plan that leverages all of the DA assets for growth, inclusion, awareness and participation.”

Bernard received her bachelor’s degree in Political Science from Framingham State College and her master’s degree in Journalism from Boston University.

Categories: Drupal

Code Karate: Drupal 8 URL Embed Module

27 August 2019 - 7:42am
Episode Number: 223

The Drupal 8 URL Embed Module makes it easy to add embeddable URL’s into your Drupal website. What exactly is an embeddable URL? It’s an easy way to turn your links to popular social sites such as Twitter, YouTube, Facebook, Instagram, Spotify, and more into a nicely formatted embed code that displays a preview of the content directly on your site.

Tags: DrupalDrupal 8MediaSite BuildingSocial ToolsDrupal Planet
Categories: Drupal

wishdesk.com: What should you know about the plan for Drupal 9

27 August 2019 - 6:01am
Congrats, Drupal 9 release is planned for June 2020! In the meantime, you should ensure that your platform is ready for the upgrade. Although it should arrive easily and smoothly, your website still needs a plan.
Categories: Drupal

Specbee: Drupal Translation - How to create Multilingual websites in Drupal 8

27 August 2019 - 5:39am
Drupal Translation - How to create Multilingual websites in Drupal 8 Mithun 27 Aug, 2019 Top 10 best practices for designing a perfect UX for your mobile app

Want an easy way to extend your market reach and ultimately your sales? Do you feel you need to personalize your website to every user no matter which country they belong to or what language they speak? Getting yourself a multilingual website is your best bet. Not only is it a more cost-effective marketing strategy, it also helps in increasing your website traffic and overall SEO. Drupal CMS has particularly taken up this challenge of providing not only users but also developers with the ability to access Drupal in a language that they prefer. And with Drupal 8 being multilingual out-of-the-box, it has become an ideal choice for businesses and developers. Powerful Drupal translation modules offer developers with granular configuration capabilities where every content entity can be translated.

What are Multilingual Websites?

Multilingual basically means written or available in different languages. Multilingual websites connect better with users from different countries as it immediately adds an element of familiarity. Drupal 8 provides an easy and a great experience of building a multilingual website. Currently Drupal 8 supports 100 different languages for translation.

Drupal 8 has a multilingual feature which comes along with the installation interface. As soon as you install Drupal, based on the browser preference, it provides a language for your Drupal website. Based on the option selected the site is installed in that particular language. Drupal 8 basically provides 4 different modules for language and content translation. We can enable the required Drupal modules in our site and use according to our needs in the website. 

The four core modules provided by drupal are

  1. Language module
  2. Content translation module
  3. Interface translation module
  4. Configuration translation module

Let’s catch up with what each module does, its configurations and how each module can be used in our Drupal website.

Firstly, you need to enable all the 4 core modules in your drupal site. All the translation modules can be configured at path /admin/config/regional

Drupal Language Module

This Drupal 8 language module is one of the core modules located at core/modules/language. It provides a feature of adding and choosing a new language to your Drupal website. Under /admin/config/regional/language/ you can simply add a new language to your site by clicking on the “Add Language” button. It provides a list of different languages from which you can choose the language you need for the development.

Choose the preferred language from the list and add it

Once the language is added the interface will look similar to this. In the above picture, the default language of the interface is set as English and spanish is the additional language installed. The 9172/9340(98.2%) under Interface translation indicates that 9172 words out of 9340 words available for translation are translated i.e 98.2% of the words in the interface are translated.

It also provides a block( Language switcher) to switch the language from one to another which can be placed at  any region of your Drupal website. Under /admin/structure/block we can place the language switcher block with which we can switch the default language of our website.

                                                                                Language Switcher

Once the block is placed in the region we will be able to switch to the different languages in the web page itself.

Content Translation Module

The Drupal Content Translation module allows you to translate content entities such as comments, custom block, contents, taxonomy terms, users etc. In order to translate the content entities, the website should have at least two languages installed. The content translation can be configured at path admin/config/regional/content-language . It provides a list of entity types which can be translated. 

For example, click on the content configuration option that appears for each content type.

Let us consider that the content translation is being enabled for the article content type. It provides an option to decide if each subtype entity to be translatable or not. We can also change the default language for a particular content type. Each field has an option to translate its content or not. 

                                                        Content Translation Module - Choosing the content

It also provides an option to input the content in the language which is suitable for the user while adding content from the backend interface. Once the above configuration is set up and when we try to add content to the Article content type we can see a Select option with the languages installed in our site. We can select any language and add content in the particular language selected.

                                                 Content Translation Module - Select the language


Once the contents are saved, users with translate permissions will see links to Translate its content. It provides an additional tab called “Translate” along with the  "Edit" links, and you'll be able to add translations for each configured language.

                                                           
                                                         Content Translation Module - Select the languageInterface translation Module

 The Drupal Interface translation module is also a part of core module and can be easily enabled like any other drupal module. Once this module is enabled it is possible to replace any string in the interface with string which has been customized. Whenever this module encounters any string it tries to translate the particular string to the current language of the interface. If a particular translation is not available it is remembered and we can lookup into the untranslated string in the table.   

                                                                Interface translation Module


In the above example, the strings which are both translated and untranslated are displayed and we are able to modify the strings for the language that is installed as well.
The translations for the strings are put up in a single place called http://localize.drupal.org and the Localization Update module will automatically import the updated translation strings for your selected language. In Drupal 7 and previous versions, this was a contributed module. In Drupal 8 it is a part of a core module.

Configuration translation Module

The Drupal 8 Configuration Translation module allows configuration to be translated into different languages. The site name, views name, and other configurations can be translated easily using the configuration translation.

                                                                        Configuration translation Module

 

It also provides an option to input the content in the language which is suitable for the user while adding content from the backend interface. Once the above configuration is set up and when we try to add content to the Article content type we can see a Select option with the languages installed in our site. We can select any language and add content in the particular language selected.
Having a Multilingual website is a great way to building better and stronger relationships with users and prospective customers. Drupal 8 offers 100 languages to choose from to translate your website effectively. With Drupal 8 translation modules in core, developers now find it easier to install and adapt to a multilingual environment while providing businesses with great digital experiences.


 

Drupal Planet Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe Shefali ShettyApr 05, 2017 Recent Posts Image Drupal Translation - How to create Multilingual websites in Drupal 8 Image How to make Interactive Websites and why you need one? Image AMP It Up! The Why and How of Drupal AMP (And what it can do to your website) Explore Our Drupal Services TAKE ME THERE Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

link

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

link

Develop an internal portal aimed at encouraging sellers at Flipkart to obtain latest insights with respect to a particular domain.

link
Categories: Drupal

Hook 42: Hook 42 on Women's Equality Day: Facing Challenges In Tech

26 August 2019 - 2:06pm
Hook 42 on Women's Equality Day: Facing Challenges In Tech Lindsey Gemmill Mon, 08/26/2019 - 21:06
Categories: Drupal

Promet Source: Exciting Awards, Awesome Clients!

26 August 2019 - 11:56am
Promet Source is humbled to announce that this summer, two websites that we designed and developed for our clients have won three prestigious awards. 
Categories: Drupal

1xINTERNET blog: Atomic Design: Consistency that pays off

26 August 2019 - 10:54am
Atomic Design: Consistency that pays off jule Mon, 08/26/2019 - 19:54

Web design has changed significantly in recent years. 

In the past all pages of a website were designed individually. Designers often did not pay attention to the re-use of elements, but rather treated all pages separately.

When websites started growing in size and complexity, this often led to inconsistent user experiences, because existing templates were used to display content they were not designed for.

Today, a much more holistic approach to web design is needed, taking current, changing, and future requirements into consideration.

Categories: Drupal

Hook 42: Drupal Core Initiative Meetings Recap - August 19th-23rd, 2019

26 August 2019 - 4:47am
Drupal Core Initiative Meetings Recap - August 19th-23rd, 2019 Alona Oneill Mon, 08/26/2019 - 11:47
Categories: Drupal

Jacob Rockowitz: How top US hospitals approach their online appointment request form

26 August 2019 - 3:24am

My previous post explores how requesting a medical appointment online begins a patient's digital journey. A hospital's appointment request form might be a new patient's first interaction with a healthcare institution. As such, it is one of the most public-facing forms for a healthcare institution, establishing the baseline for the quality of other external and even internal facing forms. The user experience of the appointment request form sets the tone for the entire patient experience.

Experience

A patient's successful user experience when finding, filling out, and submitting an appointment request form is determined by the visual, information, and interactive design of the website and form itself.

Visual design matters

Visual design identifies a healthcare institution’s brand and aesthetic. The quality of care at a healthcare institution is reflected on their website. The website's visual design should be clean, efficient, and caring. Since an appointment request form results in a call back from a live person, including a photograph of a nurse or clinician on the form or landing page can visually reinforce this expectation and experience.

Information design matters

Information design ensures that the patient understands how to navigate the form and makes it clear what information is required and what information is optional. Appointment request forms act as an ambassador of sorts, beginning an interaction between a patient and healthcare clinicians. The form's information design and corresponding editorial sets the tone of a patient's interaction with a healthcare institution.

Interactive design matters

Interactive design improves the flow and process for filling out a...Read More

Categories: Drupal

Pages