Hi,

*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

-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to