Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 83464

Summary: Please make redhat-switch-mail use intltool
Product: [Retired] Red Hat Linux Reporter: Christian Rose <menthos>
Component: redhat-switch-mailAssignee: Ngo Than <than>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: kenneth, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-18 08:15:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 82319    

Description Christian Rose 2003-02-04 17:38:01 UTC
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 18:03:58 UTC
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

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

* 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 23:39:36 UTC
mitr added a patch for this in bug 82319.

Comment 3 Ngo Than 2003-08-12 10:30:56 UTC
it's renamed in RHL 9. the correct name is redhat-switch-mail.

Comment 4 Ngo Than 2003-08-18 08:15:21 UTC
it's fixed now in 0.5.20-1 or newer.