Should you go for trendy new free web fonts for translated websites (even though Times New Roman is experiencing a comeback on the web!) or should you go with tried and true when you are choosing a font? Yes, I know the art director in you wants to be consistent with what you have chosen on the English site but that font may not support the characters of your translated language site.
But what about that free web font that says it supports a number of languages! Should you use it? Are you safe?
This blog is part 2 in a series on web fonts (we’re starting to see a trend) because we have run into yet another instance of a free web font that says it supported Vietnamese and yet we found that it was not inclusive of all the characters in the language.
You can read part 1 of our series on the Google font Karla and its support of French. When a font is created and it is published that it supports multiple languages, I am always suspect. Does it really cover all the Latin Extended and Latin Extended Additional characters (if it’s a Latin based language)? Unless the font developer is a speaker of that language and the font is developed for that language, I am skeptical. Should you take the risk that something will not display correctly? What does that impact? Will it lose you a customer? Will it impact readability, comprehension, appear full of errors? What is the outcome….
Here is our case study on how we determined what the font issue was with a client’s website that was using the DejaVu Sans with a Vietnamese translated website. They had the site initially developed and translated a few years ago and had chosen DejaVu Sans at that time – version 2.35 to be exact. We were brought in to do some updates to parts of the website and provide the Vietnamese translation. When we noticed that a character was missing the tone mark which is shown as a dot under the character, we delved into the code on the page to see what was happening.
We were looking specifically at the Latin small letter e with circumflex and dot below (7879 character decimal – IEC7 character hex) as seen in the image to the left. This is an example of a character that has a “combined diacritic” which is not just added but designed to complement each other. This image is how it should appear.
When displaying Vietnamese, clear and distinct display of vowels and diacritics is essential. To this end, an appropriate font for Vietnamese needs to consider the position of diacritics, and how readers will distinguish them from each other, and from the vowels, when reading. People reading Vietnamese become accustomed to identifying each accented vowel separately as they read. Despite the language being written in a basically Roman alphabet, its conceptual base is the same as Chinese, so reading is less a matter of adding words to build an idea, as of identifying parts of an idea.
When we were reviewing the website, we noticed that the character was not appearing correctly. The image to the left is how we saw it on the staging server. The tone marker, which is the dot under the e has become transparent, an empty glyph. We set out to investigate. We don’t just tell our client it is incorrect. We want to provide the solution as to why since they were implementing the translation into the website.
To replicate what we see on the client’s website, we set up a local version of the paragraph with the issue and the specific font they used. We downloaded the font DejaVuSans.woff (version 2.35) from the web site. (You can right click on any web page and go to “Inspect” which will open up a new window and show you the coding as well as the resources that are used for that website). We then set up locally a CSS stylesheet and HTML file pointing to that font. Using text from the website in Vietnamese, we were able to replicate the issue of the missing glyph and the placeholder that is seen.
Then, we took our downloaded DejaVuSans font (the latest version 2.37) and converted it online from TTF to WOFF, which is the file format of a hosted font on a server. Once converted, we saved it locally and then directed the link in a local CSS file to the WOFF font. CSS looks something like this:
@font-face {
font-family: “DejaVuSans”;
font-style: normal;
font-weight: normal;
src: url(“newfont/DejaVuSans.woff”) format(“woff”);
}.deja {font-family: ‘DejaVuSans’;}
The paragraph in the HTML file calls upon the .deja class and displays the text correctly. So we know that locally, the font is fine on our end. Could it be corrupted on the staging server? We set out for more investigation on this character and found on Github, that there had been changes to the font from version 2.35 (which the client was using) to version 2.37 which we had downloaded and installed.
On Github, they list the changes that a font goes through from version to version. Here, it clearly points out that our character IEC7 which is the accented e with the tone mark below, was added at some point later after the client’s version of the font.
So it’s important to consider that when you use a free font (in this case they had to license it for commercial use), there may be changes made as they find characters which the font does not support. All of these characters have to be designed and added to the font family. Interestingly enough, it was designed and there in the bold version….but not the non-bold version.
Have a website localization project that you need help with? Want some consultation on which fonts you should use for your translated website? Contact us to discuss this further
