On Fri, 22 Mar 2019 at 13:18, Jakub Jelinek <jakub(a)redhat.com> 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