Bug 83464 - Please make redhat-switch-mail use intltool
Please make redhat-switch-mail use intltool
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: redhat-switch-mail (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
:
Depends On:
Blocks: 82319
  Show dependency treegraph
 
Reported: 2003-02-04 12:38 EST by Christian Rose
Modified: 2007-04-18 12:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-18 04:15:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Rose 2003-02-04 12:38:01 EST
Please consider making redhat-switchmail use intltool. This will significantly
ease the translation of the .desktop file entries for translators, since they
can be translated and maintained directly from the po file.
Comment 1 Christian Rose 2003-02-04 13:03:58 EST
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.
Comment 2 Christian Rose 2003-07-31 19:39:36 EDT
mitr added a patch for this in bug 82319.
Comment 3 Ngo Than 2003-08-12 06:30:56 EDT
it's renamed in RHL 9. the correct name is redhat-switch-mail.
Comment 4 Ngo Than 2003-08-18 04:15:21 EDT
it's fixed now in 0.5.20-1 or newer.

Note You need to log in before you can comment on or make changes to this bug.