Galaxy L10n Supplies is an intergalactic e-commerce platform designed to connect shoppers and merchants across galaxies, star systems, and dimensions. Whether you are a human browsing from Earth, a crystal-based lifeform shopping from the Andromeda Nebula, or a trader stationed on a lunar outpost, our platform delivers a seamless, multilingual, and interstellar-inclusive galactized shopping experience. With support for diverse currencies, atmospheric conditions, and communication formats, let Galaxy L10n Supplies bring the cosmos together.
https://drive.google.com/file/d/1zUzl--TTF5p_qNrCjQpmi0zxiHO4hLxL/view?usp=sharing
Despite not having much experience with this type of project, I learned a lot from my colleagues about identifying hard-coded strings and how to address them. I also realized how important the testing phase is in the development process. At first, some content didn’t localize correctly, which taught us that we needed to go back and investigate the issues within those strings. Overall, without paying close attention to testing, we could have failed at completing the internationalization and localization for this website. The testing phase helps detect bugs and errors that developers or translators may overlook in isolation, and it ensures that users in every market receive a high-quality, seamless experience. Finally, the website, including the payment section, looked fully localized into Japanese, and I think everything appears accurate for the respective locale.
The first lesson from this project is that an i18n framework must be planned at the beginning of development. Retrofitting i18n after the UI is already built introduces unnecessary complexity by requiring locating hardcoded strings, rewriting UI logic, and ensuring that all components can retrieve text from a centralized source. Even though this website had a simple structure, it still took significant time to restructure elements such as the Navbar and other UI components that originally contained inline text. In a real production environment, where codebases are larger and more layered, the cost of retroactive i18n integration would increase quickly. Building an i18n-friendly architecture upfront makes the codebase cleaner, more scalable, and easier for both developers and localization teams to maintain. The second lesson is that modern JavaScript provides many built-in i18n tools that greatly reduce development effort when used correctly. Throughout this project, I relied on APIs such as Intl.NumberFormat for currency formatting, Intl.DateTimeFormat for locale-specific date patterns, and formatToParts to detect date input order. These tools allowed the interface to adapt automatically to different locales without writing custom logic. Externalizing all user-facing text into JSON also made the website easier to scale and eliminated issues caused by hardcoded strings. Combined with targeted CSS adjustments that supported language expansion, these techniques demonstrated how existing frameworks can handle most i18n requirements efficiently when integrated with a clear plan.
After seeing these issues real-time, I see how important it is to have everyone on the same work timeline, same workflow, and to involve everyone at the start of localization. I also realized how meticulous and detail oriented one must be to catch these mistakes as it has many strings of code.This was a great way to practice communication and find a deeper appreciation for desktop publishing and software works as well.
I was quite intimidated coming into this class because I did not take the Programming Course last Spring, but despite the difficulties in learning different concepts and workflows of software i18n and l10n, and with the help of my peers (especially my group members), we were able to gain a better understanding of the different processes that we could use for this project. I mainly worked on the PM side and also acted as a linguist for the target language. Through working on this project, we were able to really understand that having early engagements with all teams will prevent major reworks later on because everyone was on the same page, and bugs and issues were fixed as soon as possible. Furthermore, having a shared timeline across engineering, design, and localization was essential for a smooth workflow.