For my second PR, I worked on improving Unicode handling across event data, specifically addressing a bug where diacritics and accented characters were displaying incorrectly in event summaries, descriptions, and locations in Open Web Calendar project.
This issue affected international users whose calendars contained characters like á, ñ, ü, and ø. To fix this, I explored the ICS conversion process in events.py, added a normalization function using Python’s unicodedata.normalize("NFC"), and made sure it applied consistently to all text fields before being passed to the frontend. This required reading through the ICS parser, learning how the project structures event data, and testing with sample ICS files that contained accented characters to verify the fix.
Compared to my earlier assignments, this PR felt more like real open-source work, debugging a subtle data-handling issue, updating backend code, and manually validating changes across the UI. This contribution helped me get comfortable modifying a larger codebase and taught me how to approach encoding problems that don’t always produce obvious errors but have a real impact on user experience.
Top comments (1)
Hi,
I enjoyed reading about your contribution to Open Web Calendar, especially how you traced the issue through the ICS conversion process and applied NFC normalization consistently across event summaries, descriptions, and locations.
One small testing improvement that might complement your work is checking canonically equivalent Unicode strings explicitly.
For example, an event title containing "Café" can represent the final accented character either as the precomposed U+00E9 or as U+0065 followed by U+0301.
Both forms should normalize to the same NFC representation. Testing them in separate ICS fixtures could help prevent regressions affecting event display, search, or text comparison.
Another useful distinction is that Unicode normalization does not repair text that has already been decoded using the wrong character encoding. Keeping those two failure modes separate could make future debugging easier.
There is a related technical explanation of Unicode normalization and text transformations here:
levenshtein.net/text-normalization...
The Unicode Consortium's normalization specification is also useful:
unicode.org/reports/tr15/
Disclosure: I am affiliated with Levenshtein.net.
Thanks for documenting the investigation and your contribution to the project. This looks like a valuable improvement for users working with multilingual calendars.