On Fri, 22 Mar 2019 at 09:47, Jakub Jelinek <jakub@redhat.com> wrote:

[..]

> Just try to execute "update-po" target in gcc/ and you will see that
> only by this single command is possible to reduce gcc/po/ directory
> content by ~2MB (which is about 5% and that is only in one directory
> with translations) which says that for quite long time no one cares
> that most of the translations are not up-to-date.

The translations are provided to gcc by a different project -
translationproject.org - some translations are in very good shape, others
are lacking, but that doesn't mean translations aren't useful.
gcc has around 13000 translatable messages and quite a lot of that changes
from release to release.

Sorry to say that but you just told that that you don't know enough about maintaining translation :P

According to my personal observations this is the case in probably +90% of all open source projects so you are not the only one :)

People maintaining translations are not looking for the C or other language code changes. They don't know that something has changed in set of strings until new .po files will be generated.

Really .. they are looking only on .po files changes!!!

As there is no changes in those .po files -> translators are thinking that none of translations needs to be updated. That how it works. In other words you have only impression that some translations are in good shape.

Here is the proof:

[tkloczko@barrel gcc-9.0.1-20190312]$ (make -C obj-x86_64-redhat-linux/gcc update-po 2>&1 >/dev/null; update-po; diff -u <(cd gcc/po; ls -l *po|awk '{print $5 " " $9 "x"}') <(cd obj-x86_64-redhat-linux/gcc/po; ls -l *pox|awk '{print $5 " " $9}'))

--- /dev/fd/63 2019-03-22 12:15:31.161415161 +0000

+++ /dev/fd/62 2019-03-22 12:15:31.165424556 +0000

@@ -1,19 +1,19 @@

-1819975 be.pox

-2619276 da.pox

-2532199 de.pox

-1983130 el.pox

-3206943 es.pox

-2245685 fi.pox

-2650499 fr.pox

-1641431 hr.pox

-2705049 id.pox

-2369903 ja.pox

-2005289 nl.pox

-3184976 ru.pox

-2938716 sr.pox

-2426131 sv.pox

-2561562 tr.pox

-1688950 uk.pox

-2059085 vi.pox

-2406450 zh_CN.pox

-2466373 zh_TW.pox

+1791091 be.pox

+2370766 da.pox

+2522956 de.pox

+1987854 el.pox

+3072641 es.pox

+2260403 fi.pox

+2690109 fr.pox

+1643615 hr.pox

+2338720 id.pox

+2193995 ja.pox

+1995932 nl.pox

+3176529 ru.pox

+2592373 sr.pox

+2410896 sv.pox

+2210663 tr.pox

+1700251 uk.pox

+2017485 vi.pox

+2258622 zh_CN.pox

+2364447 zh_TW.pox

As you see 100% of .po file has been changed/updated!!!

Above output only rises other question: why the <censored> gcc is not using standard gettext am/ac support in build trees? but this is is less important :)

What generally above tells?

That after every change in the code in the strings wrapped by _() or wrapped by other macros should cause instant  "make -C po update-po" or "ninja -C . <package>-update-po" to let know those guys that something has been changes in translations and give them chance to they work properly.

All this mess with translations is result of *assumptions* made by many code maintainers that it-work-somehow-and-I-don-need-to-know-how(tm). No .. everything has its own facts context and as long as you are not aware of those facts you only yet another small "cut" in "death by thousands cuts" result.

That is really shame that only few maintainer are fully aware of that and they are regularly after each change in the code  testing update .po files update result and even instantly committing those .po files changes with with actual code change.

Some maintainers at least remember to do that final .po files update as one of the last steps before make/tag new release.

Few (those who are able to plan better) are doing that in week or two in advance before the make release to send translators signal that something needs to be updated, and to have as much as possible updated all translation when finally release will be made.

As automake/autoconf/libtool tooling IMO is generally death (and GNU maintainers are even acting like ostriches not replying on any calls to make new automake/autoconf/libtool releases or pass control of the repos) I think that maybe at least meson could take care of keeping up to date translations by taking care of warning that .po files are not updated on executing "dist" target .. because all those updates should be done manually but by build framework/tooling automatically.

However as tolling still lacks of some features as I told in mean time *MAJORITY of ALL* OSS projects maintainers don't know about above details and they are thinking (like you) that every change in the code instantly/magically propagates to all translators ..

No .. that is not how it should works.

So please Jakub make some readjustments in your procedures and please keep all possible .po files up-to-date because without that all translations will be lagging BY DEFINITION .. ALWAYS.

And as I'me telling about general methodology of maintaining .po files it is yet another "small" detail related to encoding of .po files. I've just checked that and gcc is affected by other issue as well.

[tkloczko@barrel gcc-9.0.1-20190312]$ find . -name \*.po | xargs grep Content-Type | grep -v UTF-8

./libstdc++-v3/po/de.po:"Content-Type: text/plain; charset=ISO-8859-1\n"

./libstdc++-v3/po/fr.po:"Content-Type: text/plain; charset=ISO-8859-1\n"

./libcpp/po/ca.po:"Content-Type: text/plain; charset=ISO-8859-1\n"

./libcpp/po/be.po:"Content-Type: text/plain; charset=utf-8\n"

./libcpp/po/eo.po:"Content-Type: text/plain; charset=utf-8\n"

./libcpp/po/id.po:"Content-Type: text/plain; charset=ISO-8859-1\n"

./libcpp/po/zh_CN.po:"Content-Type: text/plain; charset=utf-8\n"

./libcpp/po/el.po:"Content-Type: text/plain; charset=iso-8859-7\n"

./gcc/po/be.po:"Content-Type: text/plain; charset=utf-8\n"

./gcc/po/id.po:"Content-Type: text/plain; charset=ISO-8859-1\n"

./gcc/po/el.po:"Content-Type: text/plain; charset=utf-8\n"

Why above is wrong? Simple .. gettext tools on generate binary .mo files are preserving original encoding used in .po files. What it means? It means that on displaying those translated messages in case of using UTF-8 based locale settings (which is now *common*) glibc needs to load additional translation table to convert those messages to UTF-8 before they will be displayed.

So please do "for i in libstdc++-v3 libcpp gcc; do make -C $i/po update-po" then convert all above files to UTF-8 using iconv -> change in all those .po file lines to "Content-Type: text/plain; charset=UTF-8\n" and .. THAN commit all those updates.

kloczek

--

Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH