Good point.
Each UI language element has to be separately identified in Launchpad, the translation tool that is being used to create the different Tatoeba locales.

Some of them are actually used as variables in other UI language elements in that tool, in order to avoid multiple (and possibly conflicting) translations of the same element.
But that was done without consideration for the declination problem you mention, because the persons who did had no notion that these could be declined in other languages than the ones they knew.
So although using variables in UI elements looks smart, at first sight, it should be proscribed, and each UI language element should be translatable separately.

Ideally, Tatoeba should be developed on a framework that handles internationalisation, with the management of locales, and not rely on an external tool for localisation.

Tatoeba uses gettext to localize text. The problem you describe can probably be solved by using the so-called contexts [1]. This allows to have different translations of the same original string for different contexts. For instance "French" in the context of a language list may have a different translation than "French" in the context of "French example sentences". Impersonator, do you think this would solve the problem?

[1] https://www.gnu.org/software/ge.../Contexts.html