One of our core principles is solidarity with each other and with our communities.
As a part of living this principle, Consensus takes on occasional projects that have the potential for high impact but lack the necessary budget for custom development.
We have some standard templates for such projects, so we can spin them up quickly for review by the clients, and deploy them to low- or no-cost hosts, appropriate to the amount of traffic they are expecting.
Overview of the project
Our most recent project in this category was a website to help refugees to Canada navigate the Refugee Board process. The MeetGary website was created by a team of refugee lawyers and refugee law researchers to consolidate and promote their research about how the preconceptions of members of the refugee board can put claimants at risk of being incorrectly rejected.
They emphasized communicating their research in clear language and using stories. They created storylines for over 50 typical claimants, with a wide range of backgrounds and situations. The cases provide examples of the most common misunderstandings and mistakes, and insights into how to avoid or counteract them.
Additionally, the MeetGary team has provided two peer-reviewed journal articles that can be included as evidence in the refugees’ claims.
Because this is an information site, with only occasional updates and no need to capture user information, we decided to build it using a Hugo static site generator. We use this approach for our own internal documentation and the documents embedded in several of our software projects, so we’re familiar with it as a lightweight means of producing websites quickly.
(They also happen to be very fast, but that’s not an issue on a site of this size.)
This approach lets us use a CI pipeline to make and test all changes locally and push the completed website to GitLab pages, which provides free hosting for static sites. Using this standardized approach across all our projects (even the small ones) makes our development work simpler, but it also means that if a build fails, it will never get promoted to the live site.
Additionally, Hugo provides native support for multi-language sites through the simple use of a consistent file structure and naming convention.
Each page is translated separately, but the entire navigation system (including internal links) is self-updating. Adding new languages is a relatively straightforward process of putting the files in the right place with a two-letter code in the filename.
this-file-en.md (for example) points to the English translation and
this-file-es.md would appear in the Spanish (Español) menu.
Reused pieces of text can also be added to the i18n configuration files. This allows the use of shortcodes for things like navigation arrows.
In this case, we used the feature to turn the
Go back [to another page] and
Go forward [to page] to learn more into complete sentences in all the supported languages, allowing the same functionality (and friendliness) for all users.
A Surprise Issue: RTL development
It turns out that the dev tools I am familiar with are not great at parsing bidirectional text.
Not only that, there are outstanding requests for this support that are years old. It’s not something that I’ve ever had to think about before, but (as an aside) I am annoyed on behalf of my colleagues for whom this is an ongoing issue that this has gone unfixed for this length of time.
This incorporation of RTL languages (Persian and Arabic) was the main challenge with this project, since none of our developers speak or read the languages in question. As a result, getting this right required checking in with translators in mid-project. Even though the various tools could manage bidirectional text as long as it occurred in the middle of sentences, we found that embedded shortcodes or HTML tags at the beginning of paragraphs could cause the whole paragraph to cut-and-paste incorrectly (and inconsistently).
Also, the text editor (the one I’m using now, as it happens) mirrored all the RTL text in display, which was then turned back around by the addition of the
languagedirection: rtl parameter in the
hugo configuration file.
I tried three text editors before giving up and implementing these changes manually, checking rendered blocks of text against the translated documents and sending screen shots of my local implementation back to the translators. If I had it to do over again, I would spend some time finding a native RTL editor for those pages, because this particular issue added about 20 unexpected hours to the project.
To Sum Up
In the end, we and the client are very pleased with the end result, which provides a much-needed service to a highly vulnerable group. Please share widely to maximize its benefit in the world!
For more details about this project and its associated organizations, check out the “About Us” page on the project site: https://meetgary.ca/about-us/
We've disabled blog comments to prevent spam, but if you have questions or comments about this post, get in touch!