RFC: Redesigning the L10n Architecture for Gramps Addons

Full RFC: RFC: Redesigning the L10n Architecture for Gramps Addons · gramps-project/gramps · Discussion #2462 · GitHub

A similar idea should hold for the Gramps Core translations.


1. Abstract

This RFC defines a decoupled architecture for Gramps Addon localization. The current workflow couples translation updates to addon releases, requiring manual maintainer intervention and delaying translation improvements for users. By treating localization as independent content delivered over-the-air (OTA), translation updates become independent of addon code releases. This reduces maintainer effort, simplifies repository management, and ensures runtime safety through validated localization artifacts.

2. Motivation

The current localization workflow utilizes a centralized translation platform (Weblate) but relies on a decentralized, manual distribution pipeline. This creates several bottlenecks:

  • Maintainer Burden: Maintainers must manually pull from Weblate, run extraction scripts (make.py extract-po), and bundle .mo files into .tgz release archives.

  • Release Coupling: A typo fix in a translation requires a full version bump and release of the addon code.

  • Repository Pollution: Mixing source code with .po translation data confuses contributors and bloats the git history of addons-source.

  • Fragility: A malformed translation string (e.g., mismatched %s variables) can crash the Gramps client if not caught manually.

  • Contributor burden: Translation details distract contributors from addon development.

This RFC decouples localization from addon development and release management, enabling automated translation delivery while preserving compatibility with the existing GNU gettext ecosystem.

Information on difference between l10n and i18n:
The core difference is that internationalization (i18n) is the engineering foundation that makes a product adaptable, while localization (l10n) is the cultural execution of adapting that product for a specific market. In short, i18n creates the empty framework, and l10n fills it with region-specific content

You could be right. I wouldn’t worry about it too much, though. In Gramps’ context it they hardly have separate meanings.

Sorry, just including a definition for l10n (and pre-emptively for i18n) to introduce jargon.