That kind of preprocessor would have been the main idea that could implement this, and seeing how it is already made, I suppose they only need maintainers for the languages.
Will adding i18n support affect the efficiency and size of CPython?
It depends on how it’s done.
If it’s done strictly as a preprocesor module that installs a custom meta path finder that handles a new dedicated file extension (such as .pyt for translation) then it increases only the loading time of the .pyt modules and nothing else.
A preprocessor can do only so much with static code analysis, however, so if you wish for translations to be done more thoroughly on the fly to dynamic attribute lookups, unpacked parameters, etc., you would then need to modify CPython’s core to support translations, which will affect runtime efficiency and the executable’s size.