Automating Image Link Localization in Language I/O
This article will describe how Language I/O can automate the re-writing of image links so that a translated article displays screenshots and other image content that has been localized into the same language as the text.
Disclaimer: Language I/O does not “translate” image files. If you have a screenshot in your English article that displays your English app or website, you will need to provide a similar screenshot of the non-English version of your app or website and store it in a language-specific directory (process described below) for Language I/O to be able to pull it into the translated article. If you lack the resources to generate these localized screenshots, we can provide a professional services quote to do it for you.
Step 1: Improper Storage of Image Files
Often the original articles are authored in a CRM (Client Relationship Management) platform that allows the author to upload an image file directly into the article and it is then stored by the CRM. Use of the CRM image file upload tool may be the easiest way to load the image file initially, but it often doesn’t lend itself to a predictable path for image file storage that Language I/O can use to automate the rewriting of that path to pull in the localized or translated file. For example, this is an image path that is generated when an image file is loaded into Zendesk.
<img src="/hc/article_attachments/360012011992/screenshot.png" width="508" height="316">
Language I/O needs a way to automatically rewrite the src attribute so that when we push in a Japanese translation of the English article that contains an embedded image, the Japanese article links to a Japanese screenshot. If we were to load the Japanese screenshot manually into Zendesk, it would get assigned a unique ID by Zendesk as displayed in the red text above. That unique ID changes with every image file that is uploaded and can’t be predicted by Language I/O with an algorithm or rule.
Step 2: Proper Storage of Image Files
On the other hand, if the English image is stored on server space that you control, you can store it in a language-specific directory such as:
In this case, the src attribute in the img tag embedded in the English article would look like this:
<img src="http://www.mydomain.com/images/english_images/screenshot.png" width="508" height="316">
Every English image file that is linked-to in an English article would be stored in the english_images directory. Next, when you create a Japanese (or any language) version of screenshot.png, you’ll leave the name of the Japanese image file exactly the same as the English image file (screenshot.png), but you’ll store it in a Japanese-specific directory such as “japanese_images”. In fact, you'll store all Japanese versions of your English image files with the same name as the English image file, just in the "japanese_images" directory. You'll create a "spanish_images" directory for Spanish images, etc.
This way Language I/O can create a rule that basically says whenever we translate an English article into Japanese, we should also rewrite the src attribute in all img tags in the article so that we replace “english_images” with “japanese_images.” This means that Language I/O would automatically rewrite our example img tag in the Japanese article so it looks like the below.
<img src="http://www.mydomain.com/images/japanese_images/screenshot.png" width="508" height="316">
Because the image file name is the same, simply altering the language-specific directory name means that the Japanese version of the screenshot will then be displayed instead of the English.
Other Image File Storage Conventions That Work
The above example isn’t the only way to automate image link rewriting. Language I/O rules can be triggered by a language-specific directory, a language-specific domain, a language code in a URL parameter, the image file name itself…it just has to be based on a repeating pattern. For example, maybe you don't want to have language-specific directories, you want all image files in the same exact directory. That’s fine, you can just add a language code to the file name itself so that we’re rewriting the file name. If your English image is pulled into the English article like this:
<img src="http://www.mydomain.com/images/screenshot.png" width="508" height="316">
When you create the Japanese version of screenshot.png, you would name it screenshot_jp.png and we could create a rule that wherever we see an img tag in an article, we re-write the name of the image file itself to include the language code at the end so in this case it would be:
<img src="http://www.mydomain.com/images/screenshot_jp.png" width="508" height="316">