First Dive Into an Open Source Project
As software developer living predominantly in the world of Javascript and smaller code bases, diving into a large open source project can feel like a daunting task. The overwhelming feeling of looking at large file structure and having no idea where anything lives or not knowing what anything is can be painful. However, as you would attack any issue, start small and keep plugging away one piece of information at a time.
The project I am working with is the Open Food Network, OFN, which is the flagship project for a non-profit and charity the Open Food Foundation. OFN is a website used to connect suppliers, distributors, and consumers for the sale and purchase of local produce. From its establishment in 2012 to the launch of a beta site a few years later and in 2015 the launch of its v.1 application in Australia, OFN has come a long way fast.
Setup and installation wasn’t to bad as OFN has provided a well organized README that steps you through start up of their application which consists largely of a Ruby/Rails environment. Despite having no experience in a Ruby environment the installation process proved to be similar to that of setting up a Node/Express environment.
Once OFN was installed and running locally, I took a moment to dive into the directory structure in an attempt to grasp the layout of code in hopes of finding something familiar. No luck. The directory was very organized so I knew once I could get a handle on the application I would be able to parse the files for information I would need. Since much of the code was unfamiliar I dove into the package.json file to see what dependencies OFN is using. There weren’t many so my next instinct was to dive into the gemfile. This is where I found the information I needed to start further understanding how OFN was designed.
The first familiar technology I came across within the gemfile was angular.js and although I have no experience with angular I knew I had my starting point. From here I began the process of teaching myself angular through reading docs and watching videos. Although syntactically different, Angular proved to have similar characteristics to React which is a library I am very comfortable with. When I felt I was beginning to grasp Angular I decided to dive back into the codebase in search of any familiar code dealing with the new content I had just absorbed. I came across many files containing what vaguely looked like angular… except covered in %’s. All of the files ended in .html.haml which was another technology I had never encountered.


Haml is a markup language typically used with ruby that allows the developer to easily describe the HTML doc with little repetitive code. Below is an example of haml syntax and its resulting html output. As you can see haml is an easy and clean way to throw together html. However like any other language haml has its cons such as the inability to produce inline html.

Now that I could read the front end code I could go about finding the issue I had set out to tackle, which was to identify the cause of this unintended string…

After searching the entire project for instances of this string I came to the conclusion it was related to the internationalization/localization files and the i18n dependency which, again, is a technology I have not encountered before.
i18n is a package that allows developers to easily adapted their applications to specific local languages and cultures. Although this package makes doing so easier it can prove to be a painstaking process as you must build an object for every language/culture you wish to support that is to contain a key value pair, with the value being the translated text, for each line of html in need of translation. OFM currently supports 8 languages and therefore has 8 files with ~1500 lines of translated text formatted as an object to be easily accessed when needed.
For the issue at hand, I found that none of the translation files have a key of Producer_Description_Text2, and therefore have come to a handful of possible solutions:
- OFM has moved away from using this text and removed it from the translation objects but not from the haml where the value is referenced. In this scenario the few lines of haml could simply be deleted.
- Perhaps only sometimes there will be text to place in this section and therefore should contain a conditional that checks if the key for this language exists display the value otherwise display none.
- My final guess would be that they have not yet added the Producer_Description_Text2 to the translation files and in doing so would replace the current unwanted text with the proper value intended for this space.
Diving into a project where the environment and dependencies are unfamiliar can be taxing. Its important to take a step back and find a small issue that has some sort of familiarity. Trying to solve even the simplest open source problem opens the doors to new technologies you may not have encountered otherwise. In no way am I proficient at any of the new technologies I came across but learning just a small amount of each allowed to me address an issue in a completely foreign codebase. Even the smallest exposure to a technology can seed a desire to learn a new skill.
