Bug 144073

Created attachment 63983 [details]
glibc-2.4-message-catalog-shadow.diff

suggested patch for glibc.

Reason for this patch:

Many packages contain translations for many languages directly in the
main package. For example most Gnome packages are like this.
For example gedit contains .mo files for all languages gedit is translated to
in files like

/opt/gnome/share/locale/zh_CN/LC_MESSAGES/gedit.mo

which are part of the "gedit" package.

Therefore it is currently not possible to update translations for
"gedit" without touching the "gedit" package itself. As this problem
exists for hundreds of packages in the distribution, updating
translations for a specific language because of an attractive deal
*after* a product is already released is difficult.

The above patch to glibc tries to make this easier. With this patch,

/opt/gnome/share/locale/zh_CN/LC_MESSAGES/gedit.mo.shadow

is preferred over

/opt/gnome/share/locale/zh_CN/LC_MESSAGES/gedit.mo

if the former exists.

Therefore it becomes possible to create an additional package
like "new-translations-for-big-OEM-deal-simplified-Chinese.rpm" which updates
most or even all translations in the distribution for simplified Chinese.

Thorsten just told me that he sees the following problem with
the approach described above:

If a service pack (say SP1) is released), it may contain updates of
the original .mo files. It can happen then that such updates are
ignored because older .mo.shadow files might exist.

To avoid that the problem described in comment #3 occurs, it would
be necessary to integrate the updated translations into the packages
which are updated in SP1.

For example, if "gedit" is updated for SP1, it would be necessary to
remove the updated translations for "gedit" from the special
translation update package and integrate them into the "gedit"
package.

Thorsten believes this process is tedious and error prone.

then add a stat if the .shadow file is newer than the "original"?

Yes, I already talked to Thorsten a few minutes ago and suggested that,
he was afraid that an extra stat would cost too much time.

Thorsten suggested that it might be a better idea to overwrite the
old .mo files with the new ones with the updated translations.

For example, the package with the translation updates could come with
a SuSEconfig script which copies all translation updates to the
correct place.

A disadvantage is that the MD5 sums of the .mo files which belong to
the rpms will be different then. Therefore rpm verify commands like
"rpm -V gedit" will report this, which is annoying.

But Thorsten said he considers this less serious than having to make
sure that the right translations are removed from the translation
update package and integrated into the individual packages when SP1 is
released.

Of course a SuSEconfig script copying updated translations to the
correct place would also need to check time stamps to avoid
overwriting updated translations.

But this would need to happen only once and not always at runtime.

Because a SuSEconfig script would need to do it's work only once,
it would be possible to do a more careful check which translation
is newer.

Looking only at the time stamp of the file might be misleading because
the time stamp of an .mo file might change if a package is rebuild
even though the translations have not been updated.

A script which copies could for example check the "PO-Revision-Date":

mfabian@magellan:~$ msgunfmt /opt/gnome/share/locale/zh_CN/LC_MESSAGES/gedit.mo | grep PO-Revision-Date
"PO-Revision-Date: 2005-09-03 19:37+0800\n"
mfabian@magellan:~$

Checking this at runtime from glibc is probably too costly performance wise.

A SuSEconfig script copying translation files might be ne necessary
for non-gettext based translation systems anyway. For some translation
systems it is not as easy as for gettext based translation to prefer a
.shadow file. For some systems it might be even impossible.

I don't like this .shadow suffix, but the much better idea Ubuntu is using does not work for translated shared libraries :(

So I will use the attached patch, map all locale prefix to /usr/share/locale-langpack/. The only situation where this will not work is if the package has a specialized translation (for example for de_DE), while the langpack has only a general one (for example de). But Mikes patch suffers from the same problem.

Created attachment 65109 [details]
locale-langpack patch

applied.

Can I get a SWAMP id, please? Also, will that cover just enabling patch 32 or also disabling patch 31? (Patch 31 has also supposedly already caused us bug 193098 in the meantime, but that's not confirmed yet.)

aj, could you please have a look at this?

Thorsten should comment on #15.

Anja, can I get the SWAMP id, please? Note that we might want to bundle this also with the fix for bug 199699 (currently in the process of testing by the customer).

*** Bug 193098 has been marked as a duplicate of this bug. ***

Petr, SWAMPID for this is 5990

Created patchinfo file as /work/src/done/PATCHINFO/glibc.patch.maintained. (BTW, what should the bug status become at this point?)

released