Bug 83464

Using intltool solves many problems that are present when managing and editing
translations of message entries in .desktop files (and files in many other
non-code file formats) directly. Below I'll use .desktop files as the example,
but all of this applies to all the other non-code file formats that intltool
supports.

intltool integrates the message entries in .desktop files into the application's
normal pot file, and then later merges back the translations into the .desktop
file at build time. By using this strategy, it solves the following important
problems:

* Trackability. With intltool, the status of completeness of .desktop entry
translations is tracked together with the rest of the application status on for
example translation status web pages. With direct .desktop manipulation, the
status for these translations has to be kept track of seperately (and usually
isn't kept track of at all).

* Visibility. With intltool, the .desktop entries to translate are immediately
visible to the translator as any other message at the same central place as the
other messages (the .po files), and so it's close to impossible for the
translator to forget these messages. With direct .desktop file manipulation,
this danger on the other hand is exceptionally big as each and every application
names its .desktop files differently and places them differently, and sometimes
there are many .desktop files in the same application and sometimes there are
none -- impossible to easily keep track of when you handle the translations of a
large number of applications.

* Notification. With intltool, changes and additions to the .desktop entries
propagate directly into the potfile, and gets marked the same way as other
message additions and changes, and hence, the translator gets notified of
changes. With direct .desktop file manipulation, changes in the original aren't
tracked or marked and so messages may easily have incorrect translations forever.

* Translation re-use. With intltool, the messages benefit from the translation
re-use that's used in po files. The exact same message that's used in the
.desktop file and somewhere else in the application does only need to be
translated once. Also, similar messages get appropriately fuzzy-matched, so the
translator does only need to make the appropriate changes, not translate the
whole thing again.

* Stability. With intltool, each translator does only edit his or her .po file.
With direct .desktop file manipulation each and every translator needs to edit
the same file, which may result in problems with different encodings used, and
other such accidents that ruin all translations. Also, there isn't the same
danger of cvs conflicts or file access conflicts.

mitr added a patch for this in bug 82319.

it's renamed in RHL 9. the correct name is redhat-switch-mail.

it's fixed now in 0.5.20-1 or newer.