Our main topic is HIV stigma, but this blog exists thanks to WordPress community who shared their knowledge with us – with me. That’s why I feel I have to give something in return now, publicly explaining how I manage to create a multilingual WordPress system without dedicated plugins. And for free.
Obstacles I found
When Alex “Gifter” and I decided to build our site through WordPress, we were already thinking about a multilingual blog – Italian and English but gave up because no external service or plugin was the right one for us.
After experimenting WPML, Polylang, TranslatePress or other solutions, we realized that nothing covered all our needs: mine, as a visually impaired blogger depending on accessibility accomodations. And Gifter’s, he perfectly sees but has no technical skills so can’t help me out properly when accessible interface is missing.
What about a multisite setup or a second WordPress installation on the same hosting? We thought of it for a while, then skipped those options as they required too much maintenance and we couldn’t afford it.
However, let’s forget problems now, they are water under the bridge and I prefer to focus on my positive experience because WordPress, over time, has improved significantly offering us possibilities we could not even guess until recently.
The block editor
Implemented in 2018 as first stage for content management, Gutenberg block editor has evolved over the years and became default system for building and editing an entire website without any programming skills.
While it yet has far fewer features than other famous products used by WordPress professionals, this editor addresses my most important need, digital accessibility – I covered this topic better at WordPress accessibility day 2024, where I have presented this same experience together with the person who taught me how to use block editor and to become confident with it.
Multilingual WordPress blog: the basic structure
I avoid going into detail about how block editor works because it is not the focus of this article, I will however just say that every page or post on WordPress is made of a content but also the template, a component which in addition to visual appearance, takes care of user interface, common elements for any post or page: menu, header, footer, sidebars… Templates are a blog’s “clothes”.
So if I want to make some posts and pages speak in English, it’s essential to build compatible templates: one header in Italian, the other in English, and same for each common element – menu included.
Unfortunately, it’s not currently possible to duplicate templates so we’re obliged to use manual copy-paste of individual blocks from a template to another, then translating its contents; annoying operation but, done once, it’s done forever.
After having built common parts – english-header / italian-header – and so on, we can use each of those parts to build corresponding english-post and italian-post templates. An essential recommendation is to give templates explanatory names, to avoid getting confused and assign wrong layout to wrong contents.
We also must have “duplicated” versions of static pages: home, about us, and so on, where we set appropriate templates. The procedure of assigning a template must be done manually every time we publish an article, I haven’t found any solution to do it automatically yet.
Is the workflow complicated? Probably, but the adventure did not end there. Then again, “free multilingual blog without plugins” does not agree with “simplicity,” it’s up to bloggers to choose between investing money on services, or spending time and patience to build something very personal and special for themselves. Gifter and I chose the second option and now we are very proud of this solution we own completely.
The challenge continues
To manage multilingual blog consistently we created two main categories: Italian and International, where we publish Italian and English posts, and tags are translated as well – except for common words used in both languages (“HIV” and “Stigma” for example).
Next comes the most difficult stage: each section is organized thanks to a very powerful block, “Query Loop.”
Its role is to filter content according to criteria set in the block’s options: filter by author, categories, tags, custom posts or even keywords. And in case you have (as in our blog) serialized stories, you can instruct the block to display titles in alphabetical order.
So I’ve committed to setting Query Loops from Italian on Italian pages and from International on English, so that there is no confusion in sorting content.
Search, error page and archives
Templates were working, content was organized but some conditions were creating problems:
- Search engine provided results in Italian and English, results page header and footer were in Italian. Very confusing for readers.
- Error page (404 page not found) was in Italian with no possibility to translate it.
- Archives (author, categories and tags) had the standard template in Italian and there was no way to make them work in English.
For search engine issue we hired an external developer who provided us with some custom code that could filter results according to given templates: if the page is Italian it shows only results in Italian, if it is in English only English.
Then for “page not found” errors I used an “artificial intelligence” creating a few code lines following instructions I provided:
Create a WordPress plugin which handles 404 pages: if browser language is Italian, transfer me to 404-it page, if browser language is NOT Italian, take me to 404-en.
On each solution I also added an instruction that would change WordPress’s language depending on post’s language, since leaving the default one meant that voice synthesizers used by people with disability would read content in Italian if it was in English, or vice versa.
Could I, a web creator with a visual impairment, maintain a blog affected by such a serious accessibility issue? The “shoemaker wearing broken shoes” is not a pleasant effect. So I used a chatbot once again and created other scripts which switched Italian or English language depending on content’s author and category.
Over time I noticed that 404 errors were displayed correctly by users, while they were ignored by automated system used to check problems and eventually help me fix them. No way, that method had to be changed with no further discussion.
But as multilingual category and tags archive had not an easy to implement solution, I gave up and made a drastic decision: avoid showing them as links in articles and remove taxonomies from search engine indexing, so as to avert any kind of inconvenience.
IntelliBuilder and shortcodes
It was definitely a bad situation as it looked like having an issue closed and four opened. To reverse that trend, I searched for a “conditional” block plugin: show or hide one or more blocks if this or that event occurs.
Intelli-Builder was one of them and it promised to satisfy my need: if the browser speaks a given language, show or hide given content.
Unfortunately it was another failure and I was giving in to the evidence of a problem with no solution, until a fortunate coincidence happened.
I was reading some code snippets at work and noticed similarities between the program I was studying and shortcodes, a method used by WordPress to instruct content to be shown or hidden, or change, according to that special code’s parameters.
Again, I used with so-called “artificial intelligence” to help me and started sending questions:
- Do you know what WordPress shortcodes are?
- Do you know how to create a plugin that hides content when it’s inside a shortcode?
- Can a shortcode change WordPress interface’s language by checking browser’s language?
Considering answers the AI gave me, I prompted it this way: create a plugin that registers two shortcodes, “ita” and “eng”: the content enclosed in Ita must be shown if the browser language is Italian and you have to change WordPress in Italian. The blocks enclosed in “eng” must be visible if user’s browser speaks a language other than Italian, and you have to change WordPress interface language to English.
Last step: I add a parameter wp=“1” (default) that along with showing content, changes WordPress’s interface language. If WP=“0” it just shows or hides the content, without changing WordPress language.
These shortcodes apparently solve our language inconsistency problems, so they will gradually replace old methods used in search result pages and 404 error page.
Conclusion
Free multilingual WordPress without plugins? Goal partially achieved. It took a couple of customizations in the code and I included them as plugins for my own convenience, but if you want you can install a component called WpCode and copy the shortcode generator directly there.
No payment? Really? We didn’t spend a single penny on this project. But if we wanted to give a price on the hours we poured into research, learning, and experimenting, it would be a small fortune. A multilingual WordPress without plugins? Gifter and I built it ourselves! I’m especially proud, as I didn’t think I had the time or patience for such a big project.
Leave a Reply