For my third Hacktoberfest contribution, I worked on a fascinating project called Faker C++. This C++ library, inspired by the well-known Faker.js, is designed to give developers a flexible tool for generating realistic fake data. This repository had several open issue to choose from, I picked one of the issue to familiarize myself with C++ development again.

Issue Overview

The issue I tackled was to add locale support to a specific module within the project. This enhancement was intended to allow the plant module to generate data in different languages, making the library even more adaptable for developers around the world. This change would provides developers with the option to create location-specific data, which is especially valuable for testing localized applications or creating demos tailored to different regions.

add locale to plant module #898

cieslarmichal posted on Sep 07, 2024

ref book module

View on GitHub

Approach and Setup

Setting up my environment took more time than anticipated. Since I hadn’t worked with C++ in a long-time, I decided to use Visual Studio for the setup that I had used in past rather than my usually IDE - Visual Studio Code. I forked the repo, cloned it locally, created a new branch and followed the contribution guidelines to download and setup the tools necessary for development. I attempted to use Bazel as the build management tool, but after a few complications, I switched to CMake with Ninja, which proved to be a more compatible setup for this project. Additionally, I had to configure clang-format to ensure my code followed the project’s specific formatting standards. To make all of these processes less-complicated and run some bash scripts, I also installed WSL on my Windows 11 operating system to use Linux-kernel. This setup phase was challenging but necessary to maintain consistency with the codebase.

Changes Made

Once the environment was ready, I focused on understanding the module’s structure and the intended changes. Familiarizing myself with the codebase was an essential step since I was working in a relatively unfamiliar environment. Fortunately, the codebase was well-documented, and the repository owner provided reference to a previous pull request that addressed similar functionality in a different module. This example provided helpful context and clarified how I should approach the code changes.

The primary code updates involved adding enUS as a default locale for the plant module, which required adding a new struct that accepted a locale parameter. This change enabled the module to generate locale-specific plant data based on user preference. I also updated the existing plant_test file to incorporate locale testing, ensuring that the new feature worked as expected and was thoroughly covered by the test cases. Testing was another area where I needed to catch up on C++, and working through this allowed me to get more comfortable with C++ testing frameworks in this case GoogleTest, which turned out to be a nice learning experience.

feat: add locale to plant module #970

mayank-Pareek posted on Oct 28, 2024

This PR introduces locale support in the plant module, with enUS set as the default.

Fixes Issue: #898

Changes:

1. Locale Parameter for Plant Definitions
   • Added getPlantDefinition() with locale as parameter to support locale-based plant data.
   • Defaulted to enUS as a fallback for undefined or unsupported locales:

   const struct PlantDefinition& getPlantDefinition(Locale locale) {
      switch (locale) {
       default:
           return enUSPlantDefinition;
       }
   }
2. Locale-Specific Naming in Plant Data
   • Updated array naming for plant data, to reflect the locale:

   const auto enUSTrees = std::to_array<std::string_view> {/* data */};
3. Test Suite Updates
   • Updated plant_test to incorporate the new locale parameter.

---

• [x] Ran all unit tests after building project to ensure no breakage from the locale addition.

View on GitHub

After finalizing the code changes, I ran clang-format and executed all the tests to ensure the modifications met the repository’s standards. The repository owner reviewed my pull request and suggested a small adjustment to include Doxygen tags for the new locale parameter to maintain thorough documentation. I quickly incorporated these changes, ensuring that the locale parameter was fully documented. After this revision and passing all checks, my pull request was successfully merged, marking the completion of my third Hacktoberfest contribution.

Conclusion

Reflecting on this pull request, I found the experience both challenging and rewarding. Setting up a C++ development environment took longer than expected, but this step helped me understand the importance of having a robust setup, especially when working on a project in an unfamiliar language. Working with testing frameworks in C++ was also a nice experience, giving me insight into how modular code can be thoroughly tested in a language like C++. In the end, this contribution not only added locale flexibility to Faker C++ but also expanded my comfort zone, helping me gain new skills that I can bring to future C++ projects.