Disclaimer:
The main propose of this email is only to flag some issues or to form some vectors/conclusions /necessary actions.
1) cogl does not build
https://koji.fedoraproject.org/koji/buildinfo?buildID=1434712
Looks like cogl library is more or less dead or at least kind of dead end.
https://gitlab.gnome.org/GNOME/cogl/
cogl is used by at least by clutter, clutter-gst, libchamplain which are used by cheese, gnome-maps, libchamplain which are then used by gnome-contacts, gnome-control-center, gnome-initial-setup and so on ..
I've been trying to flag this in https://gitlab.gnome.org/GNOME/cogl/issues/11
In that ticket, it is possible to find some links to other gnome components tickets maintainers of which I've been trying to ask about the current situation/find a workable solution.
So far .. no useful results.
Gnome mutter has own cogl and clutter copies but seems it has been bend not to be useful outside of the mutter.
I think that it would be good to invest some time to at least bring cogl to cleanly building state than some desktop developers should discuss on how to approach to cogl/clutter code from long term perspective.
2) Almost all gnome translations are not-up-to-date.
As long as cogl issue is related to only a few gnome components, I just realised that this issue stretches waaaay beyond the gnome.
Despite huge effort of all translators around the world almost all gnome packages have not updated/properly maintained translations :(
All because one small issue that most of the source code maintainers literally *never* executed "make -C update-po" or in case of meson using projects "meson <project>-update-po" then commit all changes generated changes to source tree to inform translators that they have something to update.
The same is in case of gnome help files ("meson help-<proj>-update-po" target).
All this happens because all frameworks helping maintain translations are basing only on .po files, and all translations updates are maintained *outside* original source tree.
To update .po files new .pot file needs to be generated (which contains generated list of untranslated strings to translate) then combining .po and .pot file new/updated .po file is generated adding new strings or commenting out all those entries which need to be updated.
More or less current result of above is that almost all projects which have .mo files after call during build *update-po targets are .. *SMALLER*!!
All this because i most of the cases many strings which are no longer used in current code version are still in .po files, and they are populated to end packages .mo files.
When I found the above I've been thinking for a quite long time was only:
*How to solve this class of issue with minimum effort?*
(Because this issue is affecting now thousands of projects .. not only gnome one).
After many months have yellow post-it card note on the back of my skull I think that that I have kind of idea what to change/heal this not-so-good situation instantly with that minimum effort.
That is about "what?" or identification of the issue.
So now next question is only "how?".
** I think that meson, gettext and cmake need to be changed. **
Explanation:
Part of the execution of the meson "dist" or in case automake "dist" or/and "distcheck" targets should be IMO calling meson "*-update-po" and automake "make -C po update-po" bits.
With that whoever will be doing code release will have in VCS trees modified file which should be committed.
Similar changes it would be good to apply as well for cmake i18n support.
In case of automake/autoconf all files which needs to be updated art part of the gettext.
With that relatively smalll set changes, I think that chances to have 100% up-to-date translations in any projects will grow dramatically.
When I've been working on shadow source tree usually few days before actual release, I've been commuting all .po files updates and sending kind of broadcast message to all translators to have a look on all current .po files and send me updates.
I think that something like this should be part of the open-source development cycle methodology/habits.
kloczek
--
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
