Re: Maintainers, please check if you actually depend on intltool
Hi Milan, On Mon, 3 Dec 2018 at 22:38, Milan Crha via desktop-devel-list wrote: > > On Mon, 2018-12-03 at 18:15 +, Javier Jardón wrote: > > As you probably know, for some years we have been trying to move to > > upstream gettext [1] > > Hi, > I know intltool has some issues, the projects I work on faced some of > them, but it also provides very useful tools and makes life easier to > the developers, thus I rather do not understand the need of the move to > plain gettext. If you want to discuss about the GnomeGoal, we can do it on another thread. But this is going for several years and nobody has complained before (and gettext has been improved to implement functionality only intltool provided before) > > open MR's to reflect the real dependencies of your module, that would > > be great > > I'm sorry, I never understood such requests, but it can be just me. > Consider simple "dependencies changed: dropped dependency on , > added dependency on " comment, which someone knowledgeable of the > internal things would use to make things right on the first shot, with > something like: "clone some repo, learn where things are stored, what > format is used, ideally also what implications some changes have, learn > how to test whether the change won't break anything obvious (like > compile it somehow locally at least), then open a pull request and add > it somehow in a fork of the project probably...". That's much more > complicated and discouraging for someone whom has no single idea of the > "target" project. > > I know, you said "would be great", I understand it, but I also see an > increasing demand of creating pull requests while one suggests a one- > liner change easily achievable by the maintainer in a fraction of time > with compare of all the tasks a person not working with the project at > all would do. I'm not talking about real "code" changes here, there's a > difference when someone wants to suggest a change into the project on > his/her own, which he/she also wants to test in action. Not sure it has been a misunderstanding here. I'm simply asking maintainers to confirm if they actually depend on intltool. I can do it myself but the list is quite long and I though it would be easy to simply ask for help if you don't have time / don't want create a MR a simply comment in the issue [1] would be more than welcome (sorry, maybe I should say that in the previous email) Cheers, Javier [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/104 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please check if you actually depend on intltool
On Mon, 2018-12-03 at 18:15 +, Javier Jardón wrote: > As you probably know, for some years we have been trying to move to > upstream gettext [1] Hi, I know intltool has some issues, the projects I work on faced some of them, but it also provides very useful tools and makes life easier to the developers, thus I rather do not understand the need of the move to plain gettext. Consider also code (or rather script) duplication (scripts to extract translatable strings from .desktop and various .xml files). I do not have those scripts, neither I'm sure where to get them or how to create them on my own. Changes like [4] are kind of funny, especially those where # TRANSLATORS: Don't translate this text (this is icon name) had been added. It was not needed before. Thus intltool can help to the translators as well (and the .po files did have less bogus strings). The [1] also doesn't mention a replacement to 'intltool-update -m', which I use quite often. > open MR's to reflect the real dependencies of your module, that would > be great I'm sorry, I never understood such requests, but it can be just me. Consider simple "dependencies changed: dropped dependency on , added dependency on " comment, which someone knowledgeable of the internal things would use to make things right on the first shot, with something like: "clone some repo, learn where things are stored, what format is used, ideally also what implications some changes have, learn how to test whether the change won't break anything obvious (like compile it somehow locally at least), then open a pull request and add it somehow in a fork of the project probably...". That's much more complicated and discouraging for someone whom has no single idea of the "target" project. I know, you said "would be great", I understand it, but I also see an increasing demand of creating pull requests while one suggests a one- liner change easily achievable by the maintainer in a fraction of time with compare of all the tasks a person not working with the project at all would do. I'm not talking about real "code" changes here, there's a difference when someone wants to suggest a change into the project on his/her own, which he/she also wants to test in action. Just my opinion. Bye, Milan [4] https://gitlab.gnome.org/GNOME/gnome-menus/merge_requests/1.patch ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Maintainers, please check if you actually depend on intltool
Hi, As you probably know, for some years we have been trying to move to upstream gettext [1] A lot of modules have been migrated, but is possible that change is not reflected in gnome-build-meta [2] yet (this is the repo the GNOME Release Team use to make releases) So, if you can go through the list at [3] and open MR's to reflect the real dependencies of your module, that would be great Take attention to the warning on the top of the page though! A release of your module with the dependency change should exist, if not we will have to revert to do the next GNOME release Cheers, Javier [1] https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration [2] https://gitlab.gnome.org/GNOME/gnome-build-meta [3] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/104 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
