On Fri, 22 Mar 2019 at 13:18, Jakub Jelinek <jakub@xxxxxxxxxx> wrote:
[..]
> Sorry to say that but you just told that that you don't know enough about
> maintaining translation :P
Sorry but you are wrong, it is unclear from what you are judging this. We as
the GCC project have procedures to maintain translations, new gcc.pot is not
regenerated daily but usually twice before a major release (usually at the
start of stage4 development phase and shortly before release) and on major/minor
releases, as you can see in https://translationproject.org/domain/gcc.html
It isn't worth bothering our translators with new changes every day.
The latest gcc.pot regeneration/upload was February 2nd, so there are almost
two months of further changes. While I'm not a translation maintainer, I've
spent quite a lot of time including this year working with the translators
to improve the diagnostics, so that it is better translatable or easier to
handle for the translators, see e.g. http://gcc.gnu.org/PR40883 meta-bug
and the recent changes.
In our project rules the *.po files are maintained by the
translationproject.org, we never make changes to those, just regenerate the
pot and upload it and when updates are available from translators merge
those back. I'm not going to violate this stuff with a GCC downstream
Fedora hat.
1) I don't see even single fact in what you just wrote which contradicts/undermines what I told.
You just wrote that gcc has its "own procedures" and those procedures are not the same as what I've described. In other words using some analogy you did not show that I presented apples but those apples are unhealthy and shpuld not be eaten. You said "Look Tomasz you are wrong because I have plumbs". You just described some facts on axis oriented kind of orthogonality .. only. I'm fully aware of that and this is why I wrote about readjusting some gcc procedures.
You simple ignored what I wrote and that's it.
2) It looks like even people from translationproject.org are somehow wrong or they are so polite they dpn't want to hurt gcc maintainers fillings because in the well-maintained project with i18n resources no one keeps .pot files in VCS!!!!
If you don't believe me go to for example https://gitlab.gnome.org/GNOME/ and take some random project with po/ directory and try to find in that directory .pot file. Even if you would be able to find such file in po/ it will be nothing more than the exception. Do you see this now that ggc is wasting time on maintaining .pot files content which no one is asking for?
3) gcc has a long history, and already many things are behind how some technologies/tooling should be used. I would accept that gettext support is not used as it should be used as long as .po files would be up-to-date but as I proved they are not .. You may only ask "why?" but that is all what you really should do.
I wrote that gettext support in gcc is implemented in kind of DYI way. Here is the proof:
[tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac |xargs grep GETTEXT
./libcpp/configure.ac:ZW_GNU_GETTEXT_SISTER_DIR
./intl/configure.ac:AM_GNU_GETTEXT_VERSION(0.12.1)
./intl/configure.ac:AM_GNU_GETTEXT([], [need-ngettext])
./gcc/configure.ac:ZW_GNU_GETTEXT_SISTER_DIR
Only in intl/configure.ac are used AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION macros however that directory is just copy of the gettext files. In gcc/ and cpp/ is used kind of own version aclocal macros, and in libstdc++/ gettext support is done completely DIY method.
Why? Why someone is wasting time on reinventing the wheel?
You can just remove from VCS few m4 and even some Makefile.* or Makefile files content and just enjoy use AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION macros.
If this will be done that way whole gcc build framework would be one huge step closer to have whole build framework initialised after VCS checkout by execution of "autoreconf -fiv" in gcc root directory.
Whoever as translator would be trying to update gcc .po file will be stuck with a simple thing that there is no update-po make target in any of the gcc po/ directory. That is probably the main factor why all .po files are not up to date. Whoever would be trying to do regular maintenance of .po files will be forced to decipher first DIY gcc own .po files updated procedures (not seen in any other project).
You may still try to convince me that I'm wrong and you are right, but whatever you would be able to add cannot not be able to change basic fact that translations in gcc/binutins are not well maintained (even one file).
In other words, you will be trying talking to convince those files .. not me.
People who like helping translate text resources in some projects are familiar with some exact procedures.
gcc is not using those well-known i18n maintenance procedures.
This is really end of that story. Have a good weekend :)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
