Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jun 25 2020
Jun 25

One of the things that is remarkable with Drupal 8 (and Drupal 9) is the support for multiple languages. You can translate anything, so making a page completely Norwegian is something Drupal supports out of the box.

If you download Drupal and a couple of modules, you can with just a few clicks have almost all of the interface translated into Norwegian, since translation is a community effort. This means that most of the strings we and our users see during a normal work day, are already translated by us, or someone else in the community. A very special shout out here to svenryen, who almost by himself went through all the strings in Drupal 8.

Today I want to introduce another interesting challenge, and how we are able to solve that with Drupal. Namely deploying new features that should contain translations.

At Ny Media we develop tailored and highly customized solutions for our clients. This way we ensure that their result will make their job and their business easier and more profitable. To do this, we often end up writing custom code for use either between our own projects, or for a specific client.

Translating Drupal Core is a community effort. But brand new strings coming from features that we just created in custom code is not something we can rely on the community to get translated. So we have to do it ourselves. The challenge here lies in how we can get the strings translated on the production site, when the strings are only found in this specific project. Let’s look at a couple of theoretical solutions, and then look at the solution we use. Which we by coincidence think is the best, and now we want to share this with you.

Let’s imagine that we are developing a feature where we display some Copyright information on every page, and we want to translate that. Let’s just say that we call this module “copyright_info”. And maybe we have some code that looks like this:

* Implements hook_preprocess_HOOK().
function copyright_info_preprocess_page(&$variables) {
 $variables["page"]["content"][] = [
   '#markup' => t('Thank you for visiting this site, and we hope you like the content. However it is copyrighted so please do not steal it.'),

Now on every page we will have the whole interface in Norwegian. The only exception is the part with copyright, since that is something we just wrote ourselves.

Screenshot from translated frontpage. Note the untranslated custom string. Screenshot from translated frontpage. Note the untranslated custom string.

Option 1: Translating “by hand” when the new feature is deployed.

This is the easiest and most obvious way to do it. After you have deployed your new feature, you go into the administration form for your site. This part is located under  Administration -> Configuration -> Regional and language -> User interface translation, or path admin/config/regional/translate. So we search up the string(s) we just made. Then we can translate them one by one.

String translation

This is a very transparent and easy solution. And that has its advantages:

  • Requires no additional build steps to import translations
  • Requires no additional modules to enable

However, it has some disadvantages as well:

  • Tedious to do for more than one translation.
  • Error prone (Copy-paste errors, or typos)
  • You end up having a deployed site with a temporarily untranslated string while you are manually editing the translation(s).

In this example case this might be a good solution since we only have that one string. But once you get more than 1 string to translate, you really do not want to do that by hand. And if you have a high traffic site, you probably do not want your site do be untranslated while you work.

Option 2: Exporting translation on a dev/staging site, and importing it on the live site

Another option that is available out of the box, is to export all the translated strings you have on one site, and then import them on another.

Export strings from development or staging site First you can export and download the strings from a copy of the site where your new strings are translated. Import on live site Then you upload and import the strings on the live site

This is also fairly easy to do so it does have similar advantages:

  • Requires no additional build steps to import translations
  • Require no additional modules to enable
  • Supports importing of huge amounts of text

It does however come with some disadvantages:

  • Still manual work, and might leave your site temporarily untranslated
  • Requires manual intervention
  • The translations batches are not version controlled

Option 3: Importing custom translations as a part of your build process.

As you probably have figured, this is the option I wanted to highlight in this blog post, and this is the method we are currently using in Ny Media. To achieve this we use a Drupal module called Custom translation deployments. This is a module we developed as part of a client project, which in turn ended up being our standard setup for deploying translations on our projects.

The module provides two ways of providing translations to easily deploy as part of the build process. We will look at the most simple here, and then briefly mention a slightly more advanced way.

The first step of being able to deploy translations is making sure your translations are committed to your version control system. A default Drupal installation will set the translation directory to sites/default/files/translations,. This is typically a directory ignored by the version control system. So we start this process by changing it to somewhere we can check in to our version control system. Like ../translations. To change it, we go to the page for File system located under Administration -> Configuration -> Media, or at path admin/config/media/file-system.

File settings Since the project is located one level below the Drupal installation, we place the translations in a translations folder in the root of the directory.

Here in Norway we are usually looking for Norwegian translations for our Norwegian clients. The module Custom translation deployments comes with a predefined translation file pattern defined. Meaning if we place a file called project_specifc-custom.LANGUAGE.po (or in the case of Norwegian project_specifc-custom.nb.po) in the newly defined and created translation folder, it will get imported. Let’s try that.

First let's make sure the file is in place.

$ ls ../translations

Now one can either use the interface (under Administration -> Reports -> Available translation updates - admin/reports/translations) or do this with drush.

The other convenient thing is to add this as part of your deployment script. Maybe you have some sort of Continuous Deployment tool for it, or maybe you just use some manual and run it on your server. Whatever boat you are in, you can always do something like this:

$ drush sdel locale.translation_last_checked && drush locale-update && drush cr
>  [notice] Translation file not found: http://ftp.drupal.org/files/translations/8.x/project_specific/project_specific-custom.nb.po.
>  [notice] Checked nb translation for project_specific.
>  [notice] Imported nb translation for project_specific.
>  [notice] Translations imported: 1 added, 0 updated, 0 removed.
>  [notice] Message: En oversettelsesfil importert. /1/ oversettelser ble lagt til, /0/ 
> oversettelser ble oppdatert og /0/ oversettelser ble fjernet.

This is actually 3 commands. The first one makes sure that Drush is forced to think it is time to update the translations. The second one updates the translations, and the third one clears the cache. This third step is important if you have translated strings in your JavaScript.

But it is also possible to do this through the interface. Which would look something like this.

Interface for importing a local file

One other thing to note is that having the project defined as a locale project, means you can have a translation file on a server, and Drupal will look for updates to it. As you can see from the drush output above, it will look for it in a specific pattern. This is defined as part of the hook implementation for custom_translation_deployments. So if you want a translation file for your organization you can have a custom module implementing this hook, and therefore also make it available to be updated and downloaded automatically. Her is one such example:

 * Implements hook_custom_translation_deployments_files().
function my_org_custom_translation_deployments_files() {
  $items = [];
  $items[] = [
    'name' => 'my_org',
    'project_type' => 'module',
    'core' => '8.x',
    // We set the version to something static, but not to "dev".
    'version' => 'custom',
    'server_pattern' => 'http://my_org.com/files/translations/%core/%project/%project-%version.%language.po',
    'status' => 1,
  return $items;

This way we can now either ship a translation file called my_org-custom.nb.po or a file on http://my_org.com/files/translations/8.x/my_org/my_org-custom.nb.po.

The last part I would recommend is to only look for translation updates in the local filesystem on your production server, and only manually. This way, Drupal will never try to download new translations on your live site, creating conflicts with your version controlled translations. The setting for this is at  Administration -> Configuration -> Regional and language -> User interface translation -> Interface translation settings, or path admin/config/regional/translate/settings.

Admin settings for translations

You can also do this as part of the settings on the live site, and instead keep this setting on for development sites. To do that in settings.php you would do this:

$config['locale.settings']['translation']['use_source'] = 'local';

Flexible translation methods

However your advanced methods of deployment and translation is, Drupal has a way for you to handle it. And when Drupal out of the box can not support your preferred method of deployment or automation, contributed projects like Custom translation deployments can help you the last steps of the way. The module is fully tested, used in production on many sites, and supports Drupal 9 out of the box!

If you are looking for a partner in developing your localized Drupal site, contact Ny Media!

May 29 2020
May 29

Universal design of ICT is about designing websites, apps and self-service machines so that as many people as possible can use it regardless of disability. Those who use your website may be visually impaired or blind and therefore dependent on screen readers, or people with disabilities who use keyboard only or other tools to navigate the website, or users with cognitive disabilities.

We've put together five tips on how to make the site accessible to as many users as possible.

01 Typography - make your website easy to read

Your website should be easy to read. Those who use the website may be visually impaired, may have cognitive impairment, or may simply want to scour the content of the page. Simple design concepts such as using the right size of the text, length of lines and subheadings help here.

In documents and on print it is common to use 12 dots on text, while on screen this text becomes very small. It is recommended to use 14 or 16 points instead. The text should also stand out above the background. Avoid long texts on images and, if necessary, use a  semi-transparent background color.

Long lines are harder to read, and the long distance from end to start of the next line can also interfere with the flow of reading. For a single-column page, 45 to 75 characters are considered satisfactory lengths. It also helps with the read flow that the start of each line is equal. Body should therefore be aligned to the left, not centered.

Divide the text into paragraphs and use headings and subheadings. This makes it easier to understand the structure of the text. Make sure the headings are bigger so that they are different from the body text. 

02. Contrast for the visually impaired and color blind, but also those who are out in the sun.

obile phone held up towards the sun, with reflection on the screen.

It is of little help that the text is large enough if you have light gray text on a white background. Good contrast on texts, buttons and icons is very important. This is not only for the visually impaired, but also for users who have low brightness and contrast on their screen, such as when out in the sun.

For at innholdet skal komme godt nok frem skal kontrasten være 7:1 på liten tekst (f.eks brødtekst) og 3:1 på overskrifter og større illustrasjoner, ikoner o.l. 

For the content to appear clearly enough, the contrast should be 7: 1 on small text (eg body text) and 3: 1 on headings and larger illustrations and icons.

03. Proper use of alt text

"Man with a white Guy Fawkes mask is facing camera in front of a graffiti wall.

Alt text is a texts that can be read by screen readers so that those who cannot see the image won't miss any important information on the page.

A typical mistake is to start the alt text with "Picture of ..". or "icon for ...".  The screen readers knows that the content is an image, but it needs a text to describe it to the user. Therefore, use the alt text to describing the image rather than explaining that it is an image.

It is also important to be detailed if it is important to the context. The alt text should not consist of keywords, but be a complete sentence. Examples of bad alt text for the image above would be "Person with mask, graffiti wall". A better alt text is "Man with a white Guy Fawkes mask is facing camera in front of a graffiti wall." Also, make sure the text is not too long. The maximum length of the alt text is 125 characters.

04. Make the links stand out from the text

Links in the body text can sometimes be difficult to detect, especially for the visually impaired and color blind. The links should therefore be clearly distinguished from the text around, both in color and underline. But it is not just in the design that one can make a difference, it also matters what text you use. We often see links at the end of a sentence that are named "here". For example, “Read about our services here”. Instead, you want to tell the user what the link does or what content it links to in the link text itself. A better link text would be "Read about our services".

05. Make the texts easily understandable

This tip is very much related to the first, but this is more about language and content production than design and layout. Keep in mind that some users might have some cognitive disabilities. A simpler language and shorter sentences might make it easier for these users.

  • Make your texts short and precise. Avoid writing long paragraphs that cover several topics.
  • Use bullet points if possible.
  • Simplify the language. If you use abbreviations or subject terms, it is wise to explain these the first time they are used.
  • Use images and illustrations to divide the content and to illustrate the main points.
May 29 2020
May 29

Universal design of ICT is about designing websites, apps and self-service machines so that people can use it regardless of their disability. Those who use your website may be visually impaired or blind and therefore dependent on screen readers. You may have some users with disabilities who use keyboard only or other tools to navigate the website with, or users with cognitive disabilities.

Universell utforming av IKT handler om å utforme nettsider, apper og automater slik at flest mulig kan bruke det uavhengig av funksjonsevne. De som bruker nettsiden din kan være svaksynte eller blinde og avhengig av skjermlesere.  Du kan også ha brukere på nettsiden som har nedsatt motorikk og som bruker hjelpemidler for å navigere nettsiden, eller brukere med kognitiv svikt. 

Vi har samlet fem tips for hvordan du kan gjøre nettsiden tilgjengelig for flest mulig brukere.

01. Typografi - gjør nettsiden din lett å lese

Nettsiden din skal være lett å lese. De som bruker nettsiden kan være svaksynte, de kan ha kognitiv svikt, eller de kan rett og slett ønske å skumlese innholdet på siden. Enkle designgrep som å bruke riktig størrelse på teksten, lengde på linjene og underoverskrifter hjelper til her.

På papir er det vanlig å bruke 12 punkt på tekst, mens på skjerm blir dette svært smått. Det er anbefalt å heller bruke 14 eller 16 punkt. Teksten skal også komme godt fram over bakgrunnen. Unngå at lange tekster ligger oppå bilder, og bruk i stede gjerne ensfarget transparent bakgrunn om nødvendig. 

Lange linjer er tunge å lese, og den lange avstanden fra slutt til starten av neste linje kan også forstyrre flyten i lesingen. For en side med én kolonne er 45 til 75 tegn regnet som god lengde. Det hjelper også med leseflyten at starten på hver linje er lik. Brødtekst bør derfor være justert til venstre, ikke midtstilt. 

Del opp teksten i paragrafer og bruk overskrifter og underoverskrifter. Dette gjør det lettere å forstå strukturen i teksten. Pass på at overskriftene er større slik at de skiller seg fra brødteksten.

02. Kontrast for svaksynte og fargeblinde, men også de som er ute i sola

Mobiltelefon som holdes opp mot sola, med refleksjon på skjermen.

Det hjelper lite at teksten er stor nok hvis du har lys grå tekst på hvit bakgrunn. God kontrast på tekster, knapper og ikoner er svært viktig. Dette er ikke kun for svaksynte, men også for brukere som har lav lysstyrke og kontrast på skjermen sin, for eksempel når man er ute i sola. 

For at innholdet skal komme godt nok fram skal kontrasten være 7:1 på liten tekst (f.eks brødtekst) og 3:1 på overskrifter og større illustrasjoner, ikoner o.l. 

03. Riktig bruk av alt-tekst

Mann med en hvit Guy Fawkes maske står mot kamera foran en grafittivegg.

Alt-tekst er tekster som kan leses av skjermlesere slik at de som ikke kan se bildet får med seg all viktig informasjon på siden.

En typisk feil er å starte alt-teksten med “Bilde av ..”. eller "ikon for ...".  Skjermlesere vet hva innholdet er, men trenger en tekst for å beskrive det for brukeren. Start derfor heller med å beskrive bildet enn å forklare at det er et bilde.

Det er også viktig å være detaljert hvis det er viktig for konteksten. Alt-teksten skal ikke bestå av nøkkelord, men være en fullstendig setning. Eksempel på dårlig alt-tekst her hadde vært “Person med maske, grafittivegg”. En bedre alt-tekst er “Mann med en hvit Guy Fawkes maske står mot kamera foran en grafittivegg.”. Pass også på at teksten ikke blir for lang. Maks lengde på alt-tekster er 125 tegn.

04. La lenkene skille seg ut fra teksten

Lenker i brødteksten kan av og til være vanskelig å oppdage, særlig for svaksynte og fargeblinde. Lenkene bør derfor skille seg tydelig fra teksten rundt, både med en farge og understrek. Men det er ikke bare i designet at man kan gjøre en forskjell. Hvordan man formulerer tekstene er også viktig. Man ser ofte at lenkene heter “her”, og ligger i slutten av en setning. For eksempel “Les om våre tilbud her”.  I stedet vil du fortelle hva lenken gjør eller hvilket innhold som venter i selve lenketeksten. En bedre lenketekst ville vært "Les om våre tilbud".

05. Gjør tekstene lett forståelig

Dette punktet henger mye sammen med det første, men dette går mer på språk og innholdsproduksjon enn design og layout. 

  • Gjør tekstene dine korte og presise. Unngå å skrive lange paragrafer som går over flere temaer. Bruk også gjerne punktlister. 
  • Bruk et enkelt språk. Hvis du bruker forkortelser eller fagbegreper er det lurt å forklare disse første gang de brukes.
  • Del opp sider med bilder og illustrasjoner. Dette hjelper å få fram poenget i teksten.

Kort fortalt

Du vil at nettsiden din skal være tilgjengelig for alle. Jeg har foreslått noen grep man kan gjøre for å forbedre siden, men dette er bare noen tips man kan ha i bakhodet. Har du spørsmål eller trenger hjelp til å gjøre brukeropplevelsen bedre for alle dine brukere, ikke nøl med å ta kontakt med oss.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web